The Kevin Rooke Show

Azz - 00:00:00:

If we're running code on a device we don't own, then it's open source. The code is open source, and you can see what's happening because really, you should have a right to know what's running on your device. Even if we decided to be malicious and stuff, we still couldn't take any of the funds. The hardware signer will only make your payment with its key, which actually holds your money if it receives a signature from one of your devices like your phone. The idea that software just isn't enough on its own, no matter how cool the software is, how much you optimize it and everything, having the hardware as well is so important to having everything work. Raspberry Pi are not designed to be used as a 24/7 payments device. They don't have error correct in memory in case things go wrong. Simply, the hardware is not built. Even if you had a legacy finance application where they're not doing all this cryptography and stuff, they wouldn't dare run or something like Raspberry Pi simply because the hardware is not good enough.

Kevin Rooke - 00:01:01:

Azz is the 16 year old founder of Valera company, uniting hardware and software to bring Lightning payments to billions of people. In our conversation, we discussed Indra, which is Valera's Lightning node runtime for enabling near zero cost Lightning nodes. We also discussed the idea of connecting your Lightning node to cold keys or wearable devices. And finally, we discussed the idea of using software and hardware and uniting them to build better products. Azz has also been added to today's show splits. So if you enjoy this episode and if you learned something new, the best way you can support both of us is by sending in sats over the Lightning Network. You can use any podcasting 2.0 app, but my favorite to use is Fountain. Before we get into the show, just a quick message from sponsors. Today's show is sponsored by Voltage, and Voltage is building the Lightning Network infrastructure toolkit built for engineers. Today's show is also sponsored by Stakwork. Stakwork is a Lightning powered transcription tool that takes the best of AIS and humans to create better, faster, and less expensive transcripts. We'll have more from Voltage and Stakwork later in the show. Azz, welcome to the show. I'm excited to talk about this latest project that you revealed a little bit about on Twitter the other day and the work you're doing at Valera. But before we get into it, why don't we step back and why don't you tell listeners about how you first discovered bitcoin.

Azz - 00:02:35:

So I discovered bitcoin for about a year and a half ago, roughly January, by accidentally stumbling upon Stacks, which was like bitcoin derived project, and sort of went from being interested in the project to developing in the ecosystem there. And we sort of built up a massive development community, tons of projects and stuff. But then over time, for example, I was involved in the city joint project. You might have heard of it, but over time, we sort of me and some other tour members thought more about the bitter and maxi side of things and thought more about the ethics and sort of when you get higher up into the hierarchy, you can see truly what's going on. And we did. And then as a result, we left the startup seed fund system and we've gone on to found two separate companies, Truebit and Valera, sort of we're friends. The companies aren't completely related, but we've sort of been almost like this the companies since we moved on from Stacks.

Kevin Rooke - 00:03:57:

Are you able to reveal some of what you saw at the higher up levels at Stack that turned you off from the project?

Azz - 00:04:07:

Probably just the general attitude from some of the community leaders. And it sort of because I found in my community to create technical projects and create developers and experiences that would actually change people's lives. But it ended up feeling like all the leaders want in the community is to make a buck for their pocket. Which is exactly what the Maxis have been saying the whole time. And they were right.

Kevin Rooke - 00:04:43:

Now. Okay, so you left the kind of Stacks ecosystem you decided to build on Bitcoin. When did you make that realization that it was Lightning that you wanted to build on?

Azz - 00:04:58:

Probably December, January of a year back, because we've been working on Valera roughly since Valera related things roughly since January of this year. So it's been very undercover and there's been a lot of work under there.

Kevin Rooke - 00:05:17:

And what was it about Lightning that attracted you? What made you go? Of course, this is what we built.

Azz - 00:05:24:

Ultimately the biggest change we can make in people's lives is by changing their money, changing the way money works. And Lightning has such huge potential behind it. One is just a sort of technically it's very capable currently, but also just because we're not talking about a concept anymore, even though it's relatively niche, I can make $1,000 payments over Lightning from my Node pretty easily, and I can make that in milliseconds. And that's not like a tech demo. That's like me buying like Ramen from my friends at the store today, right? I paid for that over bid runner from my enlightenment mode and stuff like that, where I can show off to them like, this is what I do at work. That's the sort of thing I want to do because likely just have such huge potential to change the world. And mostly the fits the money fits the world slogan is very true because a lot of the world's problems can be are routed back to their legacy financial system. And Lightning is the best way to onboard absolutely everybody in the world to this fairer equal financial system on Bitcoin.

Kevin Rooke - 00:06:46:

Now, was Lightning something that you discovered after leaving the Stacks ecosystem? Or had you been following along with progress over the last few years as well.

Azz - 00:06:58:

So I've only been around a bitcoin for the last two and a half years, I think roughly for Truntest, I'm 16, and so it's been quite a stepping stone personally, to get up to sort of these levels. But while I was in Stacks, I was paying attention to Lightning for a while, for quite a few months throughout how my personal payments, even though stacks was probably the main thing I was working on, I held all of my capital and stuff. I held it all in BTC, at least for the most part. And then when I wanted to spend, I've tested out basically all the mobile Lightning wallet I've used LND, I'm currently on tour Lightning on a testing server and which is working out for me great so far. But yeah, while I was at Stats, I was using mobile wallets, I was using Moon Zeus, sorry, Phoenix. Phoenix is a great wallet. I'll put that out there. I have no idea how it works behind the technical scenes, I take a few jesses, but I'm not that familiar with, let's say, Claire compared to call out in an LND. But Phoenix as an experience for me, phoenix was an awesome experience. I've also tried Breez, but personally I prefer to use in Phoenix over it. But yeah, there was definitely a lot of use of Lightning and also even discussions of bringing like, Stash sins on to Lightning. But really it was more of a personal thing and personal thing to get on Lightning.

Kevin Rooke - 00:08:44:

Yeah, that's really interesting. So you're 16 and you've been building on Bitcoin now for a couple of years, and you recently unveiled, or you kind of teased this project that you've been working on at Valera. Is it called Indra? Is that how I pronounce it?

Azz - 00:08:57:

Yeah, that's right. It's named after the Hindu god of lightning.

Kevin Rooke - 00:09:03:

Yeah, I have to look that up to see what the name was behind it. But you had this tweet Storm, and it started off with a tweet saying that you're building a Lightning node runtime called Indra using LDK. Can we maybe give everyone a high level understanding of what is a Lightning node runtime and why you chose LDK?

Azz - 00:09:30:

There's quite a few options in the Lightning space for node implementations. So you've got called Lightning, LND, massive popular one, Eclair which is less known, but also probably the third choice, and also various smaller ones that have been built specifically for mobile wallets and stuff like that, built custom. But what really stood out to us for making things stale and efficient at the stale we need them to work out was LDK because of the amount of programmability you get into, you're not just interacting with because LND and CLN, these are basically programs by themselves and you don't really have much input into them except you can book plugins. But that's not really the same thing. But you don't have to control over everything they do, like very in depth control, technical control of what they're doing. Yet with LDK they did something completely different. And basically, instead of building a Lightning node themselves, built a sort of a set of code libraries to build Lightning nodes, which is why it stood out so much to us. And as a sort of definition, a node runtime is not a node itself, but rather you just say, quote unquote, looks after other nodes, so it manages everything they need to do to stay active and work and function. So unlike a regular Lightning node, where you basically have one node, you have one public key. For example, we can have hundreds of thousands of public keys under one computer, which is a massive deal for scaling things.

Kevin Rooke - 00:11:29:

Right, and you went on in this tweet storm. I think we can just kind of like walk through it for listeners. One of your next tweets was that this will enable what you call always on semi trusted and noncustodial nodes for essentially zero cost. Can you talk through the semi trusted setup and how that works?

Azz - 00:11:51:

So the semi trusted set up is sort of you have to imagine that if you're running a Lightning node yourself, for example, on your phone or on your Raspberry Pi home, then you have all of the data available to you, all of the storing channels, storing payment information, stuff like that all happens in your node at home. No one else can see that. The way the semi trusted bit means we have the channel data, we have to store that and obviously we're not doing anything with this. It's purely on the technical side, it's literally raw bites and it's encrypted for the node. But the semi trusted means we can't spend the user's money, but we do have access to the data behind it, if that makes sense. So the data that would usually only be available to the node runner like you, if you're running it at home, that's available to us if we really wanted to. Obviously, as I said, we don't actually use that. And in the technical implementation, it's used for nothing apart from your node. And most of it is done on the client side, eg. On your app, on your phone and on your devices. And all the code for apps running on your devices will be open source, so you can see everything that's going on. Those the sort of policy we have there is if we're running code on a device we don't own, then it's open source, the code is open source and you can see what's happening because really you should have a right to know what's running on your device. For our server side stuff, we own a server and we have a right to hide what's running on them. I think that's sort of a fair deal and if we want to share access to that code, we can do so that's the semi trusted architecture is quite interesting because we can see some data, but we can't spend your money because ultimately we need your cheese to do that. But your cheese is secured on a hardware sign of that's at your house that's completely open source and will basically protect your sovereignty. Even if we decided to be malicious and stuff, we still couldn't take any of your funds. We can't confirate them or anything.

Kevin Rooke - 00:14:25:

Right. This hardware that you might run these valera node run times on, does it take the same form factor as something like a Raspberry Pi or what does that look like from a hardware perspective? And how is it different from what someone might would expect if there are.

Azz - 00:14:42:

So the node runtime that runs the Lightning nodes runs on our servers. It runs on our servers. But the runtime connects to effectively what the equivalent is of an interconnected internet connected cold card, basically. But instead of you directly interacting with your cold card, putting in a pin stuff, all it is is a little brick with a screen on it that you plug into a USB socket and then you can control it with the app open source, obviously, from your phone. And effectively what it does is that is the device that actually holds the keys to spend your coins with. That is the thing that will have a direct connection over the internet, obviously encrypted to the runtime. And whenever the runtime basically says hey, I want to spend some funds, for example, it has to go back to your hardware signer. There's no way for the run time to spend your money without the hardware signer. So they're actually very lightweight, even more lightweight than a Raspberry Pi, for example. But the sort of difference is that you don't interact with them directly when you make a payment. Instead of like pulling your code card out, you'll use a different device. Could be the app on your phone, could be a payment ring, which is one of the things we're working on but basically those devices have everything is on a everything uses cold store as in teas that are never like stored as a file on the computer, for example and other lightning Node implementations which basically store as a 500 computer. These are stored in hardware section enclaves, both on the hardware side of which is a trust in sin. But then if you have the app on your phone, put your keys inside the chip on your phone, right, and it will never come off that chip on your phone. And this is basically having a lot of devices all connected at once means we never actually need to have a hot key for Lightning and you never have to interact with your hardware signer at home because your hardware signer trusts the key that's in your phone. And basically the hardware signer will only make your payment with its key, which actually holds your money if it receives a signature from one of your devices like your phone, which also means offline payments are completely supported, right? Because your ring which is not very smart at all, all it does is when you hold it over a reader, over NFC, the point of sale terminal basically sends the almost think of it as like the Lightning invoice to your ring. Your ring does some very basic passing so it could work out the amount and stuff, then shows it to you on a little screen. And depending on how you set up your ring, for example, if it's under $10 purchase then you might just have it automatically sign it and you don't have to do any confirmation. But if you want to do a certain amount that might be a bit higher, a bit like Apple Pay, you have to have user confirmation. So actually on the back of the ring you can squeeze it and that's the user confirmation we get. A bit like how you can squeeze the tip of the epoch pro to play or pause the trash. It's the same technique where you just put it in the back of the ring and then your ring will basically use its t which never leaves. It's not hot key, it's a cold key. But that t doesn't actually spend your money, it just identifies from the ring. It authenticates that the message came from the ring. The ring then basically gives that back to the terminal and never talks to the terminal ever again unless you make another payment. So it's a very quick one way send out. The terminal will then do the effort of them using an onion message to basically go and talk to your node and basically say hey, I have an invoice here that you need to pay, I have proof that one of your devices are paid for it. Here's the signature from the device. Then that will wake up your node because in our case that node is on Lightning node runtime. So it will go to our server, our server will go okay, this looks okay, but really I don't have access to the keys. I need to send it back to your hardware signer for the actual payment to happen. The hardware signer then goes hey, I recognize this public key from the ring as is ring. This is an authenticated device. In the last hour it's made this amount of payments, it's under its hourly limit. This is all okay and in exchange then it sends the signatures, it uses its own hardware key to make the signatures to make the payment and sends that back up to injure. And basically this all happens with the tap as your hand on the pad, like a regular Visa card or something like that.

Kevin Rooke - 00:20:05:

This is fascinating.

Azz - 00:20:08:

And during that process you also get automatic end to end encrypted receipts back to your node and all the data from the transaction, all the vouchers and stuff that you might have. That's a wrap protocol that all happens automatically. All your vouchers are selected automatically for that order and pay for automatically. And all you have to do is hold your own up to it.

Kevin Rooke - 00:20:28:

Wow. So, at a very high level, there's this node runtime that's operating on your servers. It is talking to an internet connected hardware center, like a cold card. And that can then communicate with a ring or a mobile app, some other interface that you might want to use to actually make a payment if you're on your phone or you have a ring on your hand, right?

Azz - 00:20:53:

Yeah. The awesome thing is because the actual keys are disconnected from the authentication, that completely opens up the field for first party and also third party apps and hardware. Right. Because now you can also have your web browser instead of your web browser holding its own keys and managing a Lightning node in its browser and doing all that wacky stuff. To try to get that working, all it needs to do is talk to a traditional API which basically talks back to your hardware signer and it keeps its own key, which it then uses to basically prove that it is an authorized device to your hardware signer. Which means we could see like a third party. So we could make a Web ln wallet with this, right. And all they'd have to do is integrate the client side API so they wouldn't have to think about the Lightning node, they won't have to think about all the signing capabilities. It would be super easy to make. Which also it opens up so much potential for third party developers too, because now you can integrate you to basically build whatever you want on the client side.

Kevin Rooke - 00:21:58:

Where does your mind wander when you think about the things that third party developers could build? What are some of the ideas that have come to mind?

Azz - 00:22:06:

Something specifically? I remember having an app on my phone. There's a sort of similar thing in the banking side of things. Obviously it's horrible to use, but you might have seen apps that basically connect to your bank account and then do for example, they can do tracking and tracking all your transactions and do like instead of your accounting, you have to do manually. It can basically auto do all your accounting for you from your transactions directly from your bank account. And someone could build something like that with the API in the front end.

Kevin Rooke - 00:22:39:

Right, so you have this like accounting system built in and it's just pulling data.

Azz - 00:22:44:

But then you could go from that. But then also, for example, a game on your PC, right? A game on your PC to basically ask the app on your PC from like Valera, for example, and it goes, hey, I'd like to connect and use this as a Lightning integration. And all it has to do is use the same API that everything else is using. The first party apps that we will make are completely open source, which means people will be able to get inspiration from how we do things in our first party app, build them into third party apps, and really just open the whole market for other people who want to integrate it. I mean, there's so much potential there just on the front end because that allows not only do you get all the apps that will be built on the web and stuff, like with web Ln, but also all the apps and things that need their own Lightning wallet that would previously rely on custodial services now just have an immediate on boarding right to the Lightning ecosystem without needing to think about all the Lightning behind it while also not being custodial.

Kevin Rooke - 00:23:55:

Right. Wow. I want to touch on this cold key setup where you don't have to have your keys on a computer connected to the internet. You can have it on an external hardware signer. Why has this not been done before? Why aren't any other Lightning projects taking this approach?

Azz - 00:24:17:

There is a project called VLS which is Validating Lightning Signer and they are currently working on something and they have something working for LDK and CLN, I believe. We still need to check the toad out, but it's definitely going to be something we either integrate or take a lot of inspiration from for how it works onto our back end side. And even if I'll put this completely out there, but if it does it really well, then it might be cool to have some of the developers that have been working on VLS as an open source project. I think they have exactly the right steals. We just be looking for software engineers here at Valera. Exactly the right backgrounds too, so if they'd be interested this is not a job offer by any chance and we definitely need to still look into things. But that should be true then because work has already been done on this front. It's just sort of tidying up and turning it from a technically possible thing to something we can ship to billions around the world.

Kevin Rooke - 00:25:24:

I love it. What does this do to Lightning security? When you have keys stored on a cold device, what changes do you expect to see in the ecosystem when it comes to security?

Azz - 00:25:40:

Well, the thing here is that it's greatly improved, as you'd imagine, just from moving hot keys to cold keys is always a great security benefit and also privacy. But another philosophy we have here is that the hardware will basically keep any software in check. Meaning even if Valera, well, let's say, had a mass hack and decided every single person's node had to be attacked and would be stolen, like you could do with a trusted service, it would be a lot easier to do with custodial service than us. But if you say that does happen, which would be catastrophic on our end and it probably won't happen, but say if it did, they get absolutely no funds out of it, and also they'd get no data out of it either. Because not only is the keys to spend your funds on the hardware sign up, but the runtime will actually ask any unencrypted things it needs to run the node with will only be kept in memory. And as soon as the PC is shut down, it completely forgets about it. As soon as the server shuts down sorry, it completely forgets about that and every time it turns on a node it needs to basically talk to your hardware signer to basically go hey could you decrypt this for me? Can we just use this for a minute? And your hardware scientist goes yeah sure and decrease it because it can't spend your money it's just like checking so that sort of protects it too and even if you have a complete copy of our whole database be completely useless to basically a hacker if you think about it but that's only on our side. If you then go into a normal Lightning nodes which either run into hot wallets or hot keys like they do on your phone, or they just run on, let's say, a Linux machine which might not be firewalled off properly, it might have security vulnerabilities, stuff like that. Storing keys on a hot system is never a good idea, but then now that we can this is where the hardware keeps the software in check. Because you should basically never trust software that can be modified but you should have trust in your cold card. That when you turn your cold card off and turn it on again in ten years it will still work exactly the same way. Right? That cold card is never going to accidentally delete your funds if the firmware is right. And we have basically trust in the fact that the hardware is pretty secure. The hardware is basically what secures. Everything in the Web 2 world, too, because when you boot up your operating system, it talks to a hardware chip to make sure that a hacker hasn't changed the operating system that you're loading up. Right. Hardware protects basically all security, and it's the root of all trust in the system. And basically what we're doing is just making that into Lightning by basically having not only the keys, but also the access control on your hardware signer. Because not only is it like, for example, validating Lightning signer, which basically works out whether it's been stolen funds from or not, because effectively, if the runtime is going, hey, I need you to sign this, the signer shouldn't just go, oh, here, you know, it should go, oh, am I receiving money? That's fine, I can sign that instantly because you know, there's no risk to me or am I sending someone money? I don't want to do that because I haven't had proof that the user actually wants to spend this. So actually, access control is a massive part of it, too, and which is why all our client devices like the payment Rinse, first party apps and stuff, you can all set limits on them as if they were almost Visa cards, right? But they're custom limits. You can change how much you can spend hourly. You can even freeze a device. Like if you lose your payment ring, you can go on your phone and freeze its access to your funds instantly. And also, even if the Internet is down, you can do this all from Bluetooth Internet to it directly. And then if we go even further than that and then go into sort of where else did I want to do with this? Oh, my blank.

Kevin Rooke - 00:30:18:

Okay, I just want to clarify. Let's say the worst case scenario. If we can do like a compare and contrast, if I'm running a lightning node today at home, say it's on Raspberry Pi, what's the worst case scenario for something going wrong? And what is the worst case scenario in Valera? If something goes wrong, someone gets hacked. If you guys get hacked, there's no funds lost in that process. Right? Can you kind of compare and contrast?

Azz - 00:30:49:

For Raspberry Pi? Yeah, you probably lose everything. If anything, the biggest risk on Raspberry Pi is either you set it up properly and protecting it from the evil Twitter hackers who are trying to break in, or the hardware failing. Raspberry Pi's are not designed to be used as a 24/7 payment device. They don't have error correct in memory in case since go wrong. Simply the hardware is not built. Even if you had a legacy finance application where they're not doing all this cryptography and stuff, they wouldn't dare run or something on Raspberry Pi simply because the hardware is not good enough to run it. The thing that would happen, probably the worst case scenario with Valera isn't us getting hat, but probably you just getting the traditional $5 wrench attack or $10 now because of inflation. But the problem is on that front. But then that's not really a Valera issue. That's sort of a general security issue at that point. Because one of the interesting things I remember now, what I was doing today about the hardware devices, this signer that you keep at home, you don't interact with this directly, right? When you make a payment, it's not actually making a payment from your ring to the hardware device. It's going from your ring to the terminal, through the lightning outlet, into your node, into the runtime back to your signer, and then back to the runtime to make the payment. Which means if someone comes around to your house, unplugged your signer, steals it, and then tries to blackmail you, there's basically absolutely no way they can get the funds anyway because of that hardware security, because that live signer is what we're calling it. That live signer will not unlock without a valid signature from your devices, from your client devices. It won't unlock its control. It's not like a code card where you can guess the pin or something, because that's user interaction. This thing will literally just not talk to them, right? And if you want proper secure setups, for example, when you're going into generational wealth or corporate wealth, we're talking about multisig lifesigns, you can geographically distribute all of these live signs. Obviously, that adds latency, but latency is not a problem when you're submitting, when you're securing billions of dollars worth of Bitcoin, right? What's more important is not losing the billions of dollars worth of Bitcoin, right? So having them not be interactive, then they'd also have to steal multiple live signers to try and break in. Or even if you're running like a two of three set up with a multi SIG that's almost redundancy if one of the life signs breaks or gets stolen, the whole funds are still fine because you still have two signers available, right? And even if you have a Power chat at one location, the other two will still be available, right? If you want this thing scales from absolutely everything down to individual people, like a single person living in an apartment by themselves to families where they can all share one lifestyle. They don't have to buy one per person like you would with a trade car, for example. They can all just use separate access controls on the lifestyle all the way up to massive corporate vaults that are spread across multiple data centers. They might be behind massive firewalls and stuff scattered everywhere to protect all for assets. It stales from that all the way up, which is sort of the magic of the security model.

Kevin Rooke - 00:34:35:

I hope you're enjoying the show so far. Just a quick message from our sponsor. Voltage Empowers engineers with the tools to integrate Bitcoin and Lightning Network payments within their business stack. With an enterprise grade experience. The team at Voltage is building the complete toolset so that you can do more than simply spin up nodes, but you can also understand and interpret your nodes data. Their new product, Surge, gives engineers the ability to quickly solve problems and optimize their operations. With node insights and visibility through time series data, you get dynamic and complex insights that were never available before. You can get complete control of your Bitcoin and Lightning tech stack with insanely fast onboarding advanced client side encryption and zero management infrastructure to make backups networking and upgrades simple. Get a free seven day trial today at voltage.cloud.

Kevin Rooke – 00:35:28:

Now, one thing I want to bring up on the scalability side is you mentioned in your Twitter thread that you could bring the cost of operating a Lightning node down by about, I think it was 10,000x, so effectively zero. Can you talk me through how that.

Azz - 00:35:46:

Works so effectively behind the scenes. Your Lightning node, how the runtime makes it so efficient and runs so many of these at the same time is by ironically not running all of these at the same time because traditionally you might need like a server, like a virtual server for each one or pi for each one. But that doesn't scale very well and because of how CLN and the other node implementations are built that's sort of the way they expect you to use it as one node per server or a few nodes per server. What we're doing is the complete opposite, which is thousands, hundreds of thousands of nodes per server, right? We're literally the main limitation here is not actually the computer memory resources of the server, but actually the amount of ports we have available on the machine. And the Internet addresses we can actually give you that's what it's limited by, because that 480,000 comes from ten IP addresses with 48,000 ports open each. And that will probably be less per IP in production because we have to keep some open. But generally that's the sort of thing we're looking at. The way it gets down by is by not running them all at the same time and only running them when they need to be active. Basically the runtime pretends to be the nodes it's running. So for example, if you're running a call at the node, which is a full node that runs on your server to the rest of the light node to the rest of the Lightning Network, including your full node one of the nodes on Indra is a completely normal node because it's basically doing a ton of things to make it seem like it is a completely normal node. Unlike a mobile node where your mobile phone could be out of signal in some places or not be available, you can't open ports on it because of firewall and stuff and security. Instead, we will literally pretend to be your node if we need to be. For example, sometimes if there's a message in Lightning which is the pin message to basically check hey, are you awake? Basically from another Lightning node and you respond upon back very simple message but that requires absolutely no we don't actually switch your Lightning node on to actually do that. We pretend to be your node from the runtime and basically say pond for you and we don't even boot up your node in the first place. And these nodes are expected to be not routers like for example like zero fee routing or even like my personal node, but rather they're meant to be light nodes. That how many coffees do you buy a day? You don't actually use your card that often per day. So we can achieve that scale because simply you're not using it most of the time and we can shut them down and then by basically bundling all of that into one thing we can make it super efficient and basically cut the average cost down.

Kevin Rooke - 00:38:50:

Okay, that makes sense. So this is a highly efficient system where you can run up to, I think it was 480,000 nodes in one server. But there are potentially performance benefits to still operating one node, one server if you are a zero fee routing or some big routing number, is that correct?

Azz - 00:39:12:

Yes, of course. And in fact, what we're talking about here is purely the light nodes. Effectively what they are is light nodes almost. So when you think about that, compared to those light nodes will need to somewhere to send their payments over which will be one of our LSP routers. It won't be though, our routers will be custom made in LDK because we have a lot more features to add into our LSP than just the basic line capabilities. And also we want that programmability over there and we like fielding things from the ground up and engineering them to be exactly perfect for what we need them to do. So in fact, we have Indra which will run hundreds of thousands of those on one server and then we will have our own routers which will probably be closed source because they don't need to be open source because the likelihood is you won't be running these with like 10,000 transactions per second. And if your average self sovereign operation at home you can just use CLN or something else. Our LSP is very designed and custom designed and engineered for our internal networks and stuff like that. You don't really need to see the toad behind it as long as you know it's the Lightning node and that one will use. It might even run one node across multiple servers, for example, because at that stage you might need to a bit like Eclair does or the Eclair lets you do is run it over multiple servers. So there's a lot of there are two extremes I suppose because one is hundreds of thousands of transactions per second capability which is the router and then others are like not even one transaction per second on average per node.

Kevin Rooke - 00:41:02:

And so, on Indra do you expect that the ability if I'm trying to pay for let's use the classic pay for a coffee example. Will I have a faster experience on Indra or running my own node and things like that.

Azz - 00:41:16:

Indra easily. Because not only are you but also it would be way more reliable too because instead of going and relying on your node to do all the pathfinding calculations and also one of the things when you have 480,000 people making payments, one of the advantages of this is we can actually share the pathfinder, right? So usually your Lightning node learns by making payments by itself when you buy a coffee, and it tries 30 different ways, and you have to stand there for 15 seconds while it does to find the right route. And then it goes, hey, I found a good way, and then it records that route. But instead, now we've got 480,000 people doing that, and all of them have. And it's all under one pathfinder algorithm. So our algorithms that run injured not only that 480,000 person per server, but then injured runtimes can actually connect to one another. So you'll actually find them sharing and improving each other's root calculations. So that's efficient by itself. But then also if you're using Indra, you're probably going to be using LSP too. And the LSP is a beast by itself. So the sort of goal is to have 99.99% or something of the Lightning Network available at any point within two hops, which is try the liquidity job. And that just means your payments will get there a lot faster. And if they don't get there, people will try the hardest to get that payment to where it needs to be, even if that means opening a channel. Or for example, if the shop has run out of inbound liquidity and traditionally your phone would go, oh no, it shouldn't receive the payment because they didn't have enough liquidity. You won't find it out, it just said pimp failed. But for our LSP our LSP will basically brute force and splice open their channel, add more inbound liquidity to it, put your toffee payment through, close the channel zero comfort and then basically put the payment through instantly while opening the channel. A nd basically it will try it's absolute hardest to get that payment to where it needs to be. It's basically what I'm saying the idea is that the LSP does everything from currency conversions and replaces your exchanges, which is a whole new conversation, but it does everything from currency conversions with Taro and stuff all the way to a virtual channels, which are basically, if you think about it, most LSPs currently use effectively one node to source because that's most efficient. But we want to use multiple ones to lower latency around the world because we're talking about onboarding the whole world here. So our notes will need to be able to send payments to each other. But the problem is that over Lightning, you usually have to have well, you have to have channels to send the payment over. And then when you have channels, you have to think about rebalancing and stuff like that, which is a real pain when you're trying to especially when all the bitcoin the advantage of Lightning is that it's trustless. Right? But I trust myself. Our LSP node in London trusts our own LSP node in New York because we're owned by the same person. It doesn't matter if it makes a payment to the node in New York because that money is just moving between inside the same company, right? Absolutely, it makes no difference which node it exits which is why we also use virtual channels which are basically imagine infinitely sized channels that don't actually exist on chain but the nodes will appear like they do exist. And when for example, if you made a payment from London to New York or node that's connected to New York node, it will send the payment and forward the payment from London to New York without actually a channel in between it. It will basically send a message that says, hey, you need to send this payment. But then the New York one will recognize that, hey, this guy is also owned by the same company and there is no need for a channel between us and it will send over by itself. And it's sort of all those magic things in between that basically power that LSV to make it like the most reliable thing, probably more reliable than fear at that point. There's a lot there sorry to digest.

Kevin Rooke - 00:46:02:

No, that's incredible. I want to double click on the reliability because when you were talking about how you can start to learn the pathfinding from all the other nodes that are on this runtime and then share pathfinder between run times, it's almost like you're building this Hivemind that is. Now other nodes are able to collectively figure out what the optimal path for a Lightning payment might be. What do you think this does to if a lot of people come in and adopt Indra? What does this do to payment reliability on the network as a whole? Is this something that builds upon itself to the point where everyone wants to use Indra in the same way that, you know, Google search was this little Hivemind that as people started using it, as sites started getting indexed, it just became this like, beast that of course, everyone wanted to be connected to Google and wanted to be using Google. It kind of like built on itself.

Azz - 00:47:03:

Because they have the insights, yeah, they've.

Kevin Rooke - 00:47:05:

Got all the data and then of course it makes the search experience even better and then it kind of snowballs. Is that something you expect to see on Indra?

Azz - 00:47:15:

Yes, I think potentially that should be a massive thing about what you said about the Hivemind is definitely correct because even if we think about, for example, if you're in London or if you're in the UK, you'll want your node to be running in the UK servers, right? But then if you go abroad, if you're making a payment to somewhere in China and you're going from your client device in China to the shop in China, you don't want to go all the way back to London and then London all the way back to China to make that payment. So actually this is very technical detail, but the runtime actually agrees on where nodes should be and will talk basically with other injure run times and basically work out who should be running what node. So your node isn't just restricted as a regular server would be to a regular location, like one location in London, but actually it can migrate in real time to be where you are. And the nodes will actually communicate with one another. Because running two Lightning nodes at the same time is very dangerous because your debt state mess ups and stuff like that. But the good thing is we have hardware, the live signers will actually be the root of trust anyway, there will always be the people, the devices that know the channel state and they can protect against multiple instances even if injury messes up and then starts running multiple versions of the same node. Because the live signer is the one that's actually making the signatures and there's only a few of the live signers and they have their own consensus mechanism, they actually control and can protect against those events when they happen. So, yeah, it's definitely a Hivemind sort of thing, but payment reliability will definitely just effectively skyrocket almost exponentially because it's a bit like doodle, like where you have, as you said, more you had doodles in depth, in, but then more people would join in and then providing more data and insights that the doodle is using to train itself get better. But then more people are joining because suddenly it's got better. And their workers, they can't use the old search engines anymore because they're less efficient. And it's a snowballing effect because injury would basically learn so much about how the Lightning ability and have insights on basically every single channel in the network because it will have the capability to talk with other injuries who also have experience with dinner with those and you have 99.9% or whatever percent we eventually agree on putting as the goal. It will know where all of that is. And we're talking about basically combining instead of your one node, we might be combining hundreds of millions of users worth of transaction data, not in a privacy, not in a way that was threatening privacy because it's all aggregated and all it is, is basically learning the best paths. It doesn't really care that you made a trophy payment in London, right? All of that does is basically add to a store that's then combined with everyone else's store to basically work out the most efficient paths on the net.

Kevin Rooke - 00:50:48:

Interesting. Now, you are introducing a lot of new ideas in this conversation. A lot of fresh ideas that I haven't heard many people discuss. And I've had about 80 or so people on the show so far, and I'm really interested in hearing more about how you think about the things that we need to build in lightning, what your vision is for Valera as a company, and some of the frameworks that you're using to think about these ideas, because it's refreshing to see new ideas pop up in interesting ways. And to be doing all this at 16 after only being in the bitcoin space for a couple of years, it's really interesting. So I'd love to hear more about the vision for the company.

Azz - 00:51:35:

So if we go to the first question, which was like the general Lightning ecosystem as a whole, we should really just keep doing what we're currently doing, which is we're putting new concepts together, making new apps that are really cool, but also at the same time we need to be consolidating our base layer and consolidating payment reliability and actually making it work all of the time on the bottom. Because there was a really cool idea that we were discussing the other day where about a company that's working on Lightning payments and basically charging an electric vehicle with basically sats and that is an absolutely phenomenal idea, but it will not work unless your actual payments go through. They can't be taken 15 seconds to set up because it's finding a good route and then error in after you charge the 36% on your car because there's no more inbound chief, right? You have to keep working. It is actually I've submitted indra for the challenge too. So hopefully we have to see what happens out there. We have to find out specifically for the global adoption one, because I think it's a really good deal because pretty game changer by itself. And then for Valerie as a company in general, the vision is to onboard absolutely as many people are probably a similar idea to many other Lightning companies basically on board as many people as possible to the Lightning Network. But then at the same time, we don't want to be throwing these words at them like technical jargon, like the Lightning Network, because people who use cash app don't care about its engineering staff behind it. Unless you're a nerd and read their engineering blog, which, you know, do you, because I also do that. But the majority of users don't actually do that. And we have to think about that because most people don't care what a boat twelve or Bolt eleven invoice is. They don't care if they're given a bit to an address by their friend or when I want to send a payment, let's say to you, right? And say you give me my phone number and we're testing over Imessage or something similar. When I go into my wallet, I just want to see your picture there and your profile there and I want to tap your name and then I want to send you a payment. I don't care if I want to send it from my USD account, if I want to send it in pounds and then you receive it in Canadian dollars. I don't care if you want to receive it in bitcoin, that's your preference. I just want it to jet to you and I want it to get to you quickly and reliably, right? I don't care what happens underneath and basically no one else does either. The thing is, we need to think about that more because what we're doing is amazing, but most people don't care about the ins and outs of it. They just care about the end product. But then that's not the only thing because we want to open that up. None of this happens, and we don't onboard everyone if you don't have tool apps to use it with. So static news, the electric vehicle charging in all of that. That's why having third party APIs and letting absolutely everyone basically connect in and rather than limit it to almost think about imagine a Cash App, but absolutely all of your apps can basically plug into it. It's a bit like what Apple did when they introduced Apple Pay, because Apple Pay became a system wide thing. And now every app you don't want to on iOS, when you want to make a payment, when you want to buy something with there's a big Apple Pay button at the bottom and you love using it because it's so simple, right? And you know it works and it's so reliable and it's really secure too, right? If anything, Apple is sort of a big inspiration here, too, because the fusion of hardware and software that is so designed to work with one another is basically what we think will change how Lightning works overall. And we don't even want to say Lightning overall, but we want to say it's the finance system. We want to completely replace absolutely everything. And we have the potential to Lightning does currently. We just need to get it to the point where it's reliable, fast, and has all these abilities constantly, rather than sometimes your payment will go through and it would be really impressive to all your friends. And then sometimes you'll open your app and make a payment and then end up waiting 30 seconds for your payment to go through, looking very embarrassed and sorry for yourself, right? We want to absolutely blow people's minds. And for example, my friends who are sitting there in college, these people, they don't even have Cash App on their phone. When they were paying me back today for the Ramen I bought everyone, I was reading out my badge out details to them, right? But instead of that, when they download the app, they shouldn't need to buy a hardware signer. They should literally just open that up. There's no sign up, there's no please record your keys, et cetera. You literally just open the app and it's there, right? It will ask to see your contacts and some other permissions so it can work properly. But as soon as you're on board to that, and then as soon as I send you a payment, you can download the phone sorry, not download the phone, download the app onto your phone. And I should then be able to see your contact pop up in real time when you download the app. Not me closing the app, refreshing the app, and then going back to see if your name is there. I want to see it pop up in real time with your profile picture, click on you and have that same experience without you didn't need to open any channels. You don't know what a channel is. My friends don't care what a channel is. It's really cool to them, but they don't care. Right? Yeah. All I want to do is send them some money or they send me some money. It doesn't matter how that happens in the first place, as long as it does.

Kevin Rooke - 00:57:43:

Right? I think that's what it does quickly and reliably, that's something that I hope we appreciate more. As Lightning and Bitcoin development improves, I hope we start to consider some of these things that a lot of regular users who are not Lightning or Bitcoin nerds, they just don't care about. Right. At the end of the day, it is a tool and it's a useful tool, but it's not a thing. People don't want to see the tool. They just want to they want to use the tool in the background and have something magical happen on their phone. So I 100% agree with where your head is out there. I want to touch on one other point on Indra. I think at the end of the thread that you wrote introducing the project, you said you weren't sure if you're going to open source it. Can you talk me through some of the trade offs that you're thinking about in this process of whether or not to open source it?

Azz - 00:58:41:

So the biggest choice about open source in it is Indra is effectively Valera's special source. We have what no one else currently has, which is the ability to basically I don't want to truly any competitors names because I don't want to see the rest competitors, but rather partners in Lightning to the world and everything. But there is from an investment standpoint, when we're pitching to investors and stuff, they don't want to see our tech just go from being a completely game changing to then basically being given out for free because they won't get returned from it. The company basically won't be profitable and we won't have their early on advantage that we do currently, because currently we can do things for 10,000 times cheaper than everyone else. If we took that to a different market, but that was a lot less niche, that would be a huge deal, right? It would be so game change, it would probably break most of the autonomy in that industry. Luckily, we're a niche one, so Engine won't be breaking the rest of everyone else's towed and businesses, but we don't want to sort of give it away. I don't think it's ready to be given away for free quite yet. I mean, if it becomes if Centralization becomes a problem and, you know, other Lightning companies might be struggling to keep up with adoption relative to us, which would be really good, but also really bad at the same time. We will open source it, right? There's a difference between us wanting to keep our head start a bit and us completely trying to dominate the market and basically get rid of every other company that's trying to do stuff too, because that's just unfair, right? And also it's not the way to grow a community or an ecosystem that's like turning fintech into just square or just cash up. From a purely capitalist point of view, that sort of might be the one most people take is then, yes, it would be awesome just for us to have complete advantage and complete control over the whole market. But we don't want to do that because there's a lot more than, I suppose, in the current world we live in. It's more of a hyper capitalist sort of view which is purely profit user data use, privacy, individual sovereignty doesn't matter as long as you can basically break humans down to a data stream, right? That's not what we're about. We're about changing the world, but we still want to work as an actual company. So I just want to say there's definitely a limit to what we will say when we say it will be closed source and our server side stuff will be closed source. But then most of the other server side stuff that we use might not even be useful to many people because it's so highly customized to our setup and our whole tech status that it's probably not very useful to many people and is probably the most useful at least for other companies to basically onboard users with. So we have to see it's definitely not going to be a quick or an easy decision about whether it happens or not at the moment. It will stay closed source and definitely, probably for a while yet, until at least maybe quite a few months, years into production, it will be closed source. But if it does actually start being a problem, if it starts being a problem, then yes, it is worth open sourcing it and we won't hesitate to.

Kevin Rooke - 01:02:20:

Right now, let's do a hypothetical here. We get imagine some other competitor or some other companies in the space find ways to decrease the cost of running a node by 10,000x as well, right? Independent of whether you guys open source or not. If the cost is now effectively zero across the industry for running a node, what do you think about as the competitive advantage for Valera? What's the mote that you start?

Azz - 01:02:50:

It starts to be the little things that start to matter. And if other people can get to that stage, if other companies start working on this and put in the effort to build all this themselves and put it out to the stale that we do, that is utterly awesome. And I'd be very happy to have you as a competitor, right, if anything, where you've basically doubled, because it's not just about growing the company, but it's also growing. The ecosystem, because growing the ecosystem will naturally grow the company anyway, right? So it's not just a selfish approach. Like this is just like me doing this. We need to get everyone doing this too. So, yeah, I don't think it would be a problem in that scenario. If anything, it will be the little differences that start to discriminate. I mean, if you think about the difference between Breez and Phoenix isn't a lot, right? Personally, I prefer Phoenix. It's very little differences like that. For example, I just prefer how it's like a native UI rather than using Flutter, for example. That's just a very tentacle point of view, but I like the UI on Phoenix better than I do on Breez. Not as simple as that. They're very similar in functionality. But I prefer one of them and that's fine because most of our users will pick one or the other. And as long and all of our stuff that will be, you know, the payment terminals, the API protocols, stuff like that, we encourage any competitor then to then integrate them, because we want to be interoperable, because we don't want to become like a Cash App, sort of app, where it's an amazing app, but it's all locked into your Cash App. Literally, only people who use Cash App can use cash app. The advantage of Lightning is integrated absolutely everything into one another. So it would be an honor to basically, even if we build out the protocol for doing things, we want other companies to come and integrate that too into their own products, even if it's not to the same scale as we do. Just sort of having that experience. Because we're going to build that experience if it gets implemented as a standard or not. We're going for something and we're going for a vision. And whether people want to integrate that or not is up to their choice. But we're trying to make it at least the best choice that we can see, I suppose not just for us, but also for, if anything, is more for the user's choice. Because we can't just go back to being like we can't take the same values as two company and this sort of thing, which is hold onto users' data at all costs, don't let them move away from their accounts. Basically be a pain in the ass to everyone who uses your app. Especially, for example, at college, I'm switching between Node apps currently between Notability and Good Notes. It's such a pain because I want to use good nodes just because it's a little bit better and has a few different features. But then trying to get notabilities to then move all my content over from all my history and notes I've written about my subjects into good nodes is such a pain, right? But then I want the experience. Like I want to be able to download our app, use our app, open source hardware, which open source also means you can integrate it. Other companies can integrate our first party hardware into their products also if they wanted to, and even build basically a competitor using our own open source hardware. But we want people to be able to switch from our app to the competitors up to try the competitors app and then hopefully also move back to our app. But the last bit is obviously just a business move rather than anything else. Yeah, there's definitely a balance.

Kevin Rooke - 01:06:36:

Yeah. And it's important that there's interoperability. I think that's one of the things that makes Bitcoin and Lightning so special against the backdrop of Fintech is that we do have this interoperability where you can move funds and you should be able to interoperate between a lot of different apps and then you see all the different ways people are earning sats now. It's like you can earn SATS in a game, you can send them to Stacker News. You can do this. And all of it is using the same currency, which is, I think, a special feature that we should be embracing. I want to touch on one more point on you guys are focused on hardware and software. And it reminded me of a quote from Alan Kay, who helped design one of the first desktops at Xerox Park. Very influential in Steve Jobs life. And his quote was that people who are serious about software should make their own hardware. I want to hear from you about what advantages you think will emerge from the fact that you're building both hardware and software.

Azz - 01:07:46:

First of all, I love that it really matches what we're doing and sort of the values and ethics we have definitely here and where I want to take the template, because ever since we even started, everything coming together. It's been sort of the idea that software just isn't enough on its own. No matter how true the software is, how much you optimize it and everything, it won't be as true as if because ultimately it's got to interact with the real life in the real world. You want to make payments with it, you want to charge your EV with it, stuff like that. And that just matters. Having the hardware as well is so important to having everything work. In fact, there's everything from even the servers we run on. We have to think about the hardware implications of actually running this sort of thing on production service, running so many nodes on one surveys. We have to think about even the very technical things like memory corrections. If something like a solar storm comes in from the sun and accidentally flips a bit in one of your Lightning transactions and corrupts it, we need to correct that memory. Right? Many things like your last week Pi won't be able to do that and your Raspberry Pi will crash and it will just basically brick itself. It should brick itself. There's a risk it could brick itself. But for example, we use ECC memory which will then protect that. And especially because Lightning is so close to what we're doing, is so close to the metal, you could say that we're engineering a model around a hardware root of trust, right? That hardware root of trust cannot exist within anything except from something that's custom, something that we've built ourselves that fits into our model and does what we want it to do. In fact, the hardware root of trust is what protects users from any sort of circumstances where in the worst case scenario, no matter how much, like legally we protect ourselves, there will be a way, for example, a government agency to basically go, hey, we want to seize this person's funds, right? And we will have to immediately, for our own leaders sake, there's no option here. We will have to stop interacting with that user and providing services to that user. We all make that as difficult legally as we possibly can by, like, registering the Caymans and making sure legally there's a lot of protections in between that go from even separating the KYC things. We do that on board from your feet, or rather anything that interacts with the Fiat system is completely isolated, both legally and also in the compute area, too. But the servers we run our servers and services on are completely different to the ones we actually run your Bitcoin nodes on, right? There's a lot of protections and architectural designs that basically go into protecting users data at all costs. And even at that point, even if they get through all of that and we're forced to basically stop doing business with a user, we still want the user to have their funds, right? It wouldn't be right for us to then take and confiscate their funds. That is not our decision, right? If the FBI wants to go and raid their house, take all their life signings and then force them over in a legal way, over in a court or something, that is not our job, right? Our job is protecting our users from governments who might not be actually doing it for the moral, right? In countries where the government is corrupted or something. And even in like modern countries, the things that the three letter agencies get up to are absolutely insane when you start to look into it. I can pretty safely say that every single packet since 2005 that's ever been sent over a fiber cable on the internet is stored on the CIA and the NSA servers, right? There's nothing we can do about that apart from work and make choices, both architectural, legal and technical choices about how we make our sins to protect against that in the best possible way. But at the same time, we want to be compliant. We don't want to encourage money laundering or any of that rubbish or anything, but we want the system that's not our choice to offer it. We're a finance company. You're not an ethics company, right? We're not a court of law that's up for the country or wherever the thing they are. And if a three letter agency wants to see the company's assets, that is not our job to then do it for them. It's their job to get a warrant, go into their building, take the live signers, and then basically force them legally to hand over the funds. That's not our problem, right? That's not our responsibility, and we will die on that hill. That's not our problem. And the thing is and all of that relies on the hardware root of trust, right? All of that relies on your life signers, basically. Not trust in us, not trust in Valera. If Valera goes, hey, send me all your money because we've been legally forced to, your lifestyle will basically go, f off, go away. You're not taking any of this, right? Because we want it to do that. Right? We're building in hardware protections against us because software can be changed. Hardware that's at your house, protected by, you know, almost basically at that point, electrons and stuff, that's built on the hardware, we can't change, right? They will protect you at all costs, and you can trust those lifesigners will basically they will effectively brick themselves before they even give up any funds, right? If you want them to do that, they should do that. That's your choice. They're your hardware. The hardware is open source. The software that runs on that hardware is open source. You can modify it if you wanted to, but ultimately, yeah, overall, the hardware root of trust is what makes us different from a fiat company. It differentiates us from even other competitors who are just software based, because software will never beat software plus hardware. There's a reason Apple products feel so magical when you use them. Because your AirPods, when you flip the taste open, the hardware talks to the software on your phone and pops up automatically with a click. And all you have to do is press one click automatically and it does it all for you. Whereas on Android and you sort of get the mess that is Android third party hardware. Not saying anything against Android because I did have a pixel six pro for a bit, and I did try it out and I thought, I really liked it. I ran graphic OS on it for a while and it was really fun. But personally, I'm okay with the risks that there are downsides to the Apple approach. You know, there's a sort of the walled garden, then obviously we don't want the walled garden here because we don't open source in some bits. And anything that runs, if we were the equivalent of Apple iOS would all be open source. Mac OS would all be open source and will be open to pull requests from third party developers. Other companies would be helping make it a bit like Linux, right? And then some of it would be closed source, like the stuff they run on icloud. And since that work, you know, they have the full right to make their own code and don't share it with you because it's their thing. But we feel that ward environment is not the thing we want to go for. In fact, it's probably the main reason Apple products are a pain. Because apart from that, the hardware and software integration is absolutely magical. That's how Apple is able to get off the ground and basically blow absolutely everyone else out of the water when they introduced M1, right, because Intel, MD, none of them saw that coming. And then it took them years to come up and they still haven't beaten the M1's efficiency because of how tightly they've integrated it from the hardware, their electron level, all the way up to their toad level, and how good it all integrates in. And that's sort of the magic that we want to create.

Kevin Rooke - 01:16:17:

I like that analogy. Maybe to finish this conversation off, we can step back a bit and think outside of Valera, outside of the projects that you've mentioned on this podcast, what are some of the other constraints, maybe some of the critical constraints that you see preventing Bitcoin and Lightning adoption today? And how do you think we should go about fixing any additional kind of constraints? Outside of the realm of Valera.

Azz - 01:16:49:

The biggest customer for not just us, but the Lightning and BitTorrent community in general are the countries that have less developed financial systems because simply it's easier to compete if we don't have a competitor, right? It's a lot different to over here where basically we're very spoilt with the amount of fintech stuff and Apple Pay, Visa, contactless cards, all of that is basically magic over here. And there's a lot of engineering has gone into that. Even if all it is is basically putting on a very pretty face or a very ugly financial system behind it, most people around the world just only have that ugly financial system behind them, right, and even way uglier than the one we have over in the west. So the struggle is how do we get all these features and advantages over to the countries where they don't have the things we take for granted, right? Because those are the places where we can make the biggest difference. Not just on that coffee was quite cool because I made a payment over Lightning, but to the point where we're changing our communities and society works because of how the fits the money fits the world is a serious quote. And we need to think about how we're going to deliver that money to the world, if that makes sense. And that's probably the most important part, is just working out how we're going to get from the total narrow laptops to changing the lives of, you know, one of the things I want to I showed off to my friends was seeing a video on Twitter of a shop in South Africa selling sweets to kids with wallet Satoshi, right? I played the video, I paused it, I zoomed in on the video, scan the QR code, and sent them $2 from my phone instantly in front of my friends. And that was so mind blowing for them, right? But it's the people like people like that who we want to support that basically is actually the market, the first market, because obviously there's a lot more competitiveness in because we've got to beat like Apple Pay, for example. Beating Apple Pay user experience is going to be a long while out yet, even for us and for our chat. As much as we need to do, you know, there's still hardware involved and stuff like that, and people have got to get used to that over here. But we need to think about how do we bring those benefits to the people who don't have all of that in the first place?

Kevin Rooke - 01:19:22:

Makes sense.

Azz - 01:19:23:

Where they don't have Internet in every home, where they don't actually have smartphones, but rather the connectivity they have is just SMS, for example.

Kevin Rooke - 01:19:32:

Yeah, and making a magical experience may be easier, as you mentioned, in the places where they don't already have that pretty interface to rely on. And there's billions of people that can see their lives dramatically improved by this technology, and now it's just a matter of making an experience that they enjoy using. All right, let's finish this off with one final segment. It's called the Lightning round. I got a few rapid fire questions for you.

Azz - 01:20:06:

All right?

Kevin Rooke - 01:20:06:

I hope you're enjoying the show so far. Just a quick message from our sponsor. Stakwork is a Lightning powered platform for generating high quality transcripts of all your audio or video content. They combine AI engines and hundreds of human workers all over the world who are paid over the Lightning Network to assemble these transcripts. And that's what lets Stakwork create better, faster, and less expensive transcripts. To see the results for yourself, I use Stakwork on my personal website, where I transcribe all of my full-length podcast episodes. Check that out. And if you want to learn more about Stakwork, visit Stakwork.com. That is S-T-A-Kwork.com.

Kevin Rooke – 1:20:48:

First question, how many people will be operating a Lightning node in a decade?

Azz - 01:20:55:

In a decade? 250,000,000 to a billion.

Kevin Rooke - 01:20:59:

Wow. That's one of the highest numbers I've heard. I think I've heard one guest who said over a billion, but I like it if you could only hold one asset for the next decade and it could not be bitcoin. What asset.

Azz - 01:21:17:

For the next decade? Just an asset in general, or. Probably real estate. That's always a solid place to go. Usually, even if the world collapses, people will need houses. Or if you wanted to be a lot less moral. You could invest in defense companies, too, because they make a lot of money and no one's touching their defense budget for quite a while yet.

Kevin Rooke - 01:21:50:

Right.

Azz - 01:21:52:

Whether it's an ethical decision is a different problem.

Kevin Rooke - 01:21:55:

Yeah. Has there been any book that has meaningfully changed your view of the world?

Azz - 01:22:05:

The one I've got here is the Age of Surveillance Capitalism.

Kevin Rooke - 01:22:08:

The Age of Surveillance Capitalism?

Azz - 01:22:11:

Yes.

Kevin Rooke - 01:22:12:

Okay, and then final question. Is there anyone in the Lightning or Bitcoin community that you'd like to give a shout out to for the work that they are doing?

Azz - 01:22:24:

First one that comes to mind are both Lightning Labs and Dusty. Lightning Labs is working on Tara. Tara is a massive deal. A lot of people don't think it is. It's way better of a deal than people think it is, because once you sort of get we're basically tricking people into bringing their fear onto bitcoin, so then when fear inevitably collapses, everyone goes, oh, why don't we just use bitcoin instead? And to Dusty the betrayal. He's working on Splicing and he's done basically most of the work, as far as I'm aware. I don't want to put any presumptions out there, but he's done a lot of work on Splicing, which is one of the magical features that we have to integrate. And we probably have the pleasure of making a pull request into LDK to support.

Kevin Rooke - 01:23:11:

Awesome. Happy to hear that. And thank you for taking the time. This was an incredible conversation. I really enjoyed this and I hope we can do it again soon.

Azz - 01:23:20:

Sure, I'd love to. Thank you.

‍