The Kevin Rooke Show

Christian Decker - 00:00:00:

‍

So my PhD thesis was on the scalability of bitcoin, and the sort of last chapter was, hey, look, offchain protocols. We can scale using those. The whole venue of offchain protocols such as the Lightning Network is a huge boon for experimentation simply because we can carve out our own little sub chain where we can perform our experimentations. And if something goes wrong there, it is isolated to that particular part of the blockchain. The original idea for the satellite was, and still is, to bridge an eventual network split channel factories. The idea is to have one big channel and then you sort of split up into smaller channels using those funds. And so you settle the inner channels, you settle onto the outer channel. I wouldn't say as a whole network, we want open and closed channels, but we can end up in a situation where the core routing network is very stable.

‍

Kevin Rooke - 00:01:06:

‍

Christian Decker is a researcher at Blockstream who has been deeply involved in bitcoin since its earliest days in 2009. In fact, Christian even did his PhD dissertation on bitcoin. In our conversation, Christian and I spoke about Blockstream and the work they're doing on their Lightning project called Greenlight. We discussed Lightning scalability, and we even got into things like channel factories, peer swap, liquidity ads, L Two, and much more. Christian has also asked to have his share of the sats streamed in from this episode sent to the Human Rights Foundation. And there is one listener who sent in a great question for Christian who will be added to today's show, Splits. So if you want to support the show, the best way you can do that is by sending in sats over the Lightning Network. You can use any Lightning podcasting app. My favorite is Fountain, but there are many of them. If you want to earn some sats, the best way you can do that is by following me on Twitter and keeping an eye out for all future guest announcements. I'm announcing guests a day before I film with them, and when you see an announcement on Twitter, you can send in comment or question using Fountain, and I will see that. I will ask the guest that question live when we record and you will be eligible, you will have a chance at being added to the show Splits for the upcoming episode. Quick shout out before we get into today's episode. This show is sponsored by Voltage. Voltage is the industry standard and next generation provider for Lightning Network infrastructure. Today's show is also sponsored by provider for Lightning Network infrastructure. Today's show is also sponsored by Zebedee, and Zebedee is your portal into the world of bitcoin gaming. We'll have more from Voltage and Zebedee later in the show. Christian, thank you for joining me today on the show. I've got a lot of questions for you, but I want to start off with something that I saw on your website the other day. I was looking through your website and I found a blog post about bitcoin from 2010 and I want to ask about what was going through your mind at that time because this is like seven years before I even knew how to spell bitcoin. I want to understand more about what you thought bitcoin would accomplish back then. I believe I also read that you learned about bitcoin in 2009, so you were really there at the beginning and I imagine the space has shifted a lot since then. So what was that initial first couple of years like in the bitcoin community?

‍

Christian Decker - 00:03:49:

‍

Indeed, it has changed a lot now that you remind me of it. It was quite a different ecosystem and community but sort of this exploratory sort of need to look into bitcoin was always there and I think that is also reflected in that blog post as well. Sort of this excitement of stuff going on that has kept part of the community going for the last decade. But yeah, I got into bitcoin back in 2009 by stumbling over a blog post that was pointing to this weird PDF and it sort of meshed with my own interest. So I started following it and then every single news item that was mentioning bitcoin was really exciting back then. You could still have a Google news alert that would tell you every single web page that had the word bitcoin in it and you could actually read through it. So the space was really tiny. But this excitement about the technology and the possibilities was always there. And I think the blog post came out of this realization that oh yes, there are now some real use cases being built with bitcoin. This is actually going beyond my small geek community that is just looking at this from a technical perspective and then all of a sudden it is getting a financial and economic dimension too, which makes it so much more interesting as well. Right, if the technical aspect alone was interesting for us to keep us going for one to two years, getting another dimension you could dive into was really interesting as well.

‍

Kevin Rooke - 00:05:49:

‍

Did it dawn on you then that there was going to be this like big store of value use case and that there was going to be, I mean maybe the payments use case made a bit of sense back then, but how has the vision for bitcoin changed? Because now it's a store value asset that governments are adopting. Surely this wasn't top of mind back then, right?

‍

Christian Decker - 00:06:16:

‍

Absolutely not. I would be lying if I were to say that I could have foreseen even 1% of what's happening nowadays. And yes, the payments use case was something that we were thinking about on a regular basis. And in fact, even back then we started experimenting with payment channels, the first sort of realtime payment systems that were built on top of bitcoin where came out of the 2012 2013 time. So even before we sort of had a well founded understanding of the scalability limitations of Lightning of bitcoin. We were already looking at how we could keep this payment related aspect of bitcoin, but the store of value aspect I definitely did not see back then.

‍

Kevin Rooke - 00:07:12:

‍

Yeah, interesting. When you look back now, have the last few years kind of met your expectations when it comes to development on bitcoin? Like, you had all these ideas early on the payment channels, 2012, 2013, and now we're almost a decade afterwards. Do you think that we've met those expectations as the community of bitcoin developers or has that exceeded your expectations or been underwhelming?

‍

Christian Decker - 00:07:45:

‍

It probably wouldn't be true if I were to say that the expectations were exceeded, but for good reason. So a couple of years ago, we did not understand how central to the whole bitcoin ecosystem the stability of it is. And so we were much more inclined to do some really big changes that would nowadays be seen as jeopardizing the security of bitcoin simply because there wasn't as much value behind it. Right. There were not so many people relying on its stability and weren't as involved with the financials behind bitcoin. Nowadays it is imperative for us to maintain that stability for the sake of not just us, but for all of the bitcoin users in the system. And so we came to realize that we can't make these huge jumps anymore and we have to adopt a very defensive way of developing bitcoin. But we now have venues where we can experiment and where we can develop quickly and where we can make these learnings and then backport them into bitcoin. One of them definitely is the whole venue of off chain protocols, where we go from a system where everybody has to agree on changes to the protocol, to a system where you basically opt into experimentation, you opt into some more advanced use cases that you can build on top of bitcoin. And if that fails, well, you opted into that experimentation, but the rest of the network isn't impacted, whereas experimentation on the base layer is much more dangerous in that it actually has to be a global consensus and any mismatch in the logic, any error there, can be catastrophic.

‍

Kevin Rooke - 00:09:49:

‍

Right.

‍

Christian Decker - 00:09:50:

‍

I had some expectations about on chain experimentation, but I had to learn the lesson that this is definitely not something that we should pursue lightly. And sadly, some of my own proposals were rejected quite early on and that can be frustrating. And I can see many developers seeing bitcoin as a slow and sort of it's a huge cargo ship and you can't turn it around as quickly as you can some other chains, but that's for good reason and that takes some time to tool earn, basically.

‍

Kevin Rooke - 00:10:31:

‍

So do you think that by introducing things like Lightning and now you guys are working on liquid, do you expect that this will create a more vibrant developer community experimenting with new ideas and kind of like a flourishing of new bitcoin ideas.

‍

Christian Decker - 00:10:49:

‍

Absolutely. So one of the first sentences in the Liquid White Paper was exactly that. Its aim is to create an experimentation platform for the bitcoin blockchain without creating its own token. And we have been doing a lot of experimentation on Liquid. Look at confidential assets, look at confidential transactions, segwid itself. Care was experimented on Liquid first before we then sort of proposed or modified it with the learnings that we had, and then back poured it into bitcoin, where it now enables some of these use cases. Like I said before, the whole venue of off chain protocols such as the Lightning before, the whole venue of off chain protocols such as the Lightning Network is a huge boon for experimentation simply because we can carve out our own little sub chain where we can perform our experimentations. And if something goes wrong where we can perform our experimentations. And if something goes wrong there, it is isolated to that particular part of the blockchain, and there is no contagion to the rest of the blockchain. So that's a way for us to isolate and experiment and be really quick. And you've seen that experimentation a lot over the last couple of years with a lot of people jumping in, proposing changes to the Lightning Network that would otherwise have taken years to push through to the blockchain.

‍

Kevin Rooke - 00:12:22:

‍

Yeah, that's a really interesting way of framing it. I guess. There's also maybe another level where even within the Lightning Network, you're kind of like opting into different channels. And if something goes wrong in a channel between you and someone else, it doesn't affect the rest of the Lightning Network either. Right. Is there something to that structure?

‍

Christian Decker - 00:12:43:

‍

Absolutely, yeah. Simply because the way that all of these off chain protocols work is by we basically freeze a certain part of the blockchain, namely the amounts that we put into the offchain contract, be that a Lightning channel or a multiparty channel or whatever, and then we collaboratively agree on what happens with these funds. And so if anything goes wrong there, these are limited to those funds. And yes, there can be many instances of these contracts, and each channel is basically a contract that is isolated from the rest of the network, but we can then create relationships among them by forwarding payments over them.

‍

Kevin Rooke - 00:13:33:

‍

Now, when you're thinking about Bitcoin and Lightning, and you've been on the ground level in the development of it for the last decade or so, what do you think are some of the big kind of misconceptions or misunderstandings that still exist today in Bitcoin and Lightning ecosystem? You know, get up on stage, you have all the bitcoin and all the Lightning folks, all the crypto folks in one room and tell them one thing and help them just really drill down on one point that people are confused about. What would that be?

‍

Christian Decker - 00:14:17:

‍

Not sure, actually. Kind of hard. I think one learning that we've made over the years is that there is value in having a slow process, in evolving slowly and not overdoing experimentation. And sometimes it's okay to go into different directions and experiment. And the important part there is to eventually converge on to a shared system again. So one of these examples, for example, is the Lightning Network itself. When the paper came out in 2015, there were a couple of teams that went into different directions. Lightning Labs went one way, Asank went another way, and Sea Lightning went a third way. But we met back in 2016, compared nodes, and then had an honest discussion about what worked and what didn't work. And so we cherry picked the best parts of the different systems, making it with the goal of converging to a single network again.

‍

Kevin Rooke - 00:15:34:

‍

And by converging, is that the creation.

‍

Christian Decker - 00:15:37:

‍

Of the eleven bolts, that is exactly the origin story of the Lightning Network specification, is that we recognize that there is value in having one big network that allows anybody to pay anybody else rather than having three competing networks. And so we always wanted to have a one big continuous network in the end. But it was also important for us to diverge initially and have that liberty of experimenting. Because if you approach an issue from two, three different ways and then converge to the same solution, you can be sure that you've considered all different trade offs. Whereas if you basically go only one way and always go down that road, you can't be sure that there isn't a better solution. Maybe these collective learnings that we had by basically initially diverging and then converging again to write the specification, that is something that I cherish a lot in the Lightning Network process.

‍

Kevin Rooke - 00:16:49:

‍

That's fascinating. I didn't know that there was this initial divergence between the different groups. How did you all work together to ensure that when you came back together, everyone's views were being heard and everyone had the ability to share their views and kind of like influence the way the network is going to be structured.

‍

Christian Decker - 00:17:12:

‍

So it has always been a very friendly process. We've always stayed in contact, even during that moment of divergence, and we were exchanging ideas over IRC or mailing lists or what have you. And so we knew who the participants in the space were and there weren't too many. So it was also kind of much easier to make sure that everybody was in the same room and could be heard at the time. Nowadays, it's probably much harder for us to meet in a single room and be able to have a face to face directly. Then again, video conferencing got a lot better.

‍

Kevin Rooke - 00:17:56:

‍

Yeah, that's fair. In the last, let's say four or so years since Lightning was publicly released, have these groups, have these different implementations stayed relatively like? Do you think that the foundation of all these different implementations is still roughly consistent or is there divergence again? I feel like there are a number of features that I noticed are only available on one implementation today and I want to know if that is a broader trend that you're noticing or is that something that is just a oneoff feature that may be adopted by other implementations later down the road.

‍

Christian Decker - 00:18:41:

‍

So there's two different layers where we have to approach this question, right? One is what definitely should be a common shared set of rules that we all adhere to. And then there is a set of additional features that we can differentiate ourselves among ourselves on the first level where we definitely need to agree, as in hey, what protocol do we speak, how do we make upgrades, how do we implement Tap route, how do we do PTLCs instead of HTLCs? How do we do? Snore. All of these technical details that are sort of the direct peer to peer communication. That is something where we have to have a strong sort of cohesion and where we have to agree on how to collaborate. That being said, even there we do have the opportunity for experimentation. And so the Lightning Labs team, for example, has taken a very early lead on integrating Tap route into the specification and so they are currently looking at how do we build, how do we build on Tap route. There is part of the specification effort that is going into a sort of Gossip 2.0 version where we change what we gossip about in the network, how do we exchange information about the channels and nodes that are in the network. And then there's the CLM team which has been working on stuff like liquidity ads and onion messaging and stuff like that. So these are all different fragments that that part of the community has been proposing and which we are now in the process of sort of putting through the review process and getting back into the specification in order for us to make progress as a community as a whole. These are definitely parts that I expect to be eventually part of the specification. And then on the other level we have these features where people where we don't have to agree, right? These are features built on top of the Lightning Network where we can differentiate ourselves and basically add features that are specific to our use cases, right? Every implementation targets a slightly different set of users. And so that for example, is the whole URL specification where it's mostly about user to service interactions and user to node interaction, which doesn't specifically target the peer to peer protocol that the Lightning specification is talking about, or pairing processes. How do you pair your phone with a node at home, for example? These aren't necessarily something that we have to standardize, it would be nice if we could at least document them and hence the whole Blip process was born. But it's not important for the operation of the Lightning Network itself to have that cohesion in that sense.

‍

Kevin Rooke - 00:22:12:

‍

I see. So in that first bucket, that first layer of features, you figure that over time these will all be adopted by all the different limitations?

‍

Christian Decker - 00:22:24:

‍

Absolutely. Well, there's some competing proposals and we will have to hammer Well, there's some competing proposals and we will have to hammer out which one of those is better than the other and merge them by taking parts of each individual proposal and coming up with a third proposal that incorporates all the best parts of the competing proposals. It's mostly about what sort of issue are we trying to address with a certain proposal and having the best possible solution for that issue independently of who proposed who made the original proposal, basically.

‍

Kevin Rooke - 00:23:02:

‍

I see. Now, when you look at the landscape of Lightning implementations today, there's a handful of major implementations. Do you expect that number to grow over time? Do you expect more people to decide to experiment at the implementation level? Or do you expect that to contract and just have like, one or two that basically everyone uses? What are your thoughts on how that evolves?

‍

Christian Decker - 00:23:30:

‍

So I would definitely hate it if it were to contract because the collaboration of all of the teams that are working on the Lightning specifications is very important. Right. We have people from all different kind of perspectives. Some work on desktop clients, some work on mobile clients, some work on server side applications. And all of these perspectives are very important to get into the Lightning specification. If this were just one company that had sort of a set audience and they would just barrel down the road with that one vision, we would get a Lightning Network that is much, much poor because you have fewer use cases that you can address and the network as a whole would be worse. So this collaborative aspect that we have among all of the implementations is very important for me. I'd hate to lose the people that we have, and maybe we will get more teams participating. So as we learn from the building of the Lightning specification and the implementation, we can also see places where we can simplify stuff. And one of the proposals to simplify some of the ideas was written by me, Rose Beef and Rusty in 2018 called L Two. And that is something that can make the work of actually creating an implementation and getting a new team up to speed and participating in the specification much quicker because they can sort of skip all of the mistakes that we made along the way, basically. And so my hope would be to get more people involved and get more different points of view and more target audiences be represented in the specification effort.

‍

Kevin Rooke - 00:25:33:

‍

Right, that makes sense. I want to get into Green Light and talk a little bit more about what you're building there. So maybe can we start off with just a high level explanation of what are some of the biggest Lightning issues that compelled you to build Green Light?

‍

Christian Decker - 00:25:50:

‍

Yeah, so Lightning isn't easy. That's probably the understatement of the century. Because even if you were to only learn the bitcoin parts about Lightning, you'd have this huge amount of literature that you'd have to read through and you'd still only know about bitcoin. And then on top of that, you have the Lightning Network and new concepts. We have our own nomenclature, we have channels, we have liquidity, we have balancing and routing and gossip and all of that stuff. And it's not easy. It's definitely not easy, especially if you're completely new to this world of cryptocurrencies and haven't had bitcoin before. We've seen a lot of people having issues getting their friends and families onboarded onto the Lightning Network and sort of having a good time with it, right? Most people see the Lightning Network, maybe dip their toes into it and sort of notice, oh, that's maybe a rabbit hole. I don't want to spend the next ten years learning. And so there is definitely a need for us to make it easier. And one of the ways we can make it easier is to build services that take on some of the responsibilities of running a Lightning node on behalf of the user. Now that sounds very much like a custodial wallet, but as we bitcoin community have learned, custodial wallets bad. So I posed myself the challenge of basically seeing, hey, is there a way where I can take a Lightning node, take on all of the management responsibilities, but still have the user control its own keys? Because as the saying goes, not your keys, not your cards. Right? So if I were to have access to the keys, well, then you would be trusting me. Out of that idea came sort of what greenlight became and that's basically we have a service called green light where you can register a Lightning node. And we will basically create all of the database. We will create a watchtower, we will create a compute node on which the node is running. And all you need to do is basically have an app on your phone or your desktop or whatever, and that then controls the remote Lightning node. The fun part is that the Lightning node does not have its own keys. The keys are always in the app that the user is running. And whenever the Lightning node requires a signature from the keys, it will reach out to the user, ask, hey, I got this command, I'm supposed to pay this. Here is what I would change, what this would look like on the channels that I control. Are you okay with me doing this? And if yes, please give me a signature for it. So the wallet can basically independently verify that what's going on on the node is what is supposed to happen based on the commands that were issued. And if you look at it very closely, it is very close to what most of the hardware wallets are doing, right? If you have a hardware wallet back home, you have control over your keys, but where is the bitcoin node that is used to talk to the rest of the bitcoin network? It's probably run by treasurer or ledger and so they feed you the information about the bitcoin network and you basically get to sign off on all actions that happen with your funds. And so that's a very similar setup that we have here. It being Lightning. It's a bit more complex, but the basic idea is there.

‍

Kevin Rooke - 00:30:24:

‍

Right? Okay, so it's kind of like splitting the tasks of hosting and key management, keeping the keys with the user and now have hosting in the cloud. And is that the idea there that all of a sudden if it's all in the cloud, if you're managing it, you can professionally manage the hosting in a way that maybe an average user wouldn't be able to keep up with and maintain their Lightning node.

‍

Christian Decker - 00:30:52:

‍

Exactly. So the goal for us is basically to give users a node that is managed by the state of the art of operating Lightning nodes, thus taking that burden from them and just having them have a good experience. So I want to basically pull forward the good experience such that they afterwards are incentivized to learn about this stuff instead of what happens now, where you would get this 1000 page tome and you're getting told by everybody, hey, you have to read it and learn it by heart before you do your first payment. And we basically flipped out on ahead by saying, hey, it's okay, we take care of all of the hard parts for now. You go and have a good time with Lightning and see how useful it can be. And only once you're convinced that this is something that you want and that is useful for you, only then you have to do the investment and only if you really want to take on responsibility of your own nodes. So we call that onboarding educating offboarding, because our end goal for Green Light is to have no users. We want to give you a good experience in the beginning, but we also want to incentivize you to learn and take charge of your own nodes. And for that we give you all of the tools to basically run your own green light at home using Core Lightning, which is what you get with Green Light.

‍

Kevin Rooke - 00:32:30:

‍

Right? I'm not sure about where Lightning node management goes from here. I have conflicting views and I've heard different views from different people. One being like if you look at websites today, if you're building a website, you don't have a server in your basement. Often you're using AWS or something like that. And so that seems to be like the, you know, everyone's cloud hosted, right? But in the Lightning community we have this potential for going this hosted route and there's a bunch of teams building in this space, but then there's also this segment of this like, run your own node at home or there's like personal server movement. How do you see those two kind of concepts interacting over time and what wins out? Or I guess maybe are they separate use cases for the two?

‍

Christian Decker - 00:33:32:

‍

So I would rather differentiate between sort of the remoting kind of node where you have a single node that can be accessed by multiple applications and that may be a self hosted one, that may be one on a virtual public cloud or it may be on your Raspberry pi back home, versus the bundled nodes where you actually build a node into an application itself. So those are the two big differences that I see and I think the remote node would make a lot more sense because nowadays if you basically bundle a Lightning node with the application that you're trying to build. First of all. You as an application developer have to know the ins and outs of Lightning because you are the one basically instrumenting the Lightning node and trying to automate the management of the node. If not if not trying to get the user to actually actively manage the node for you. It also means that each application has their own pool of funds that are locked to that one application, right? If you have a Podcasting 2.0 app that has a bundled node, the funds that you have in that app cannot be used for, let's say, beer tap money or something like that. Whereas the remote node where you have a one single node that can manage all of the funds that basically amortizes the management needs. So you could have, you only have to set up channels once for this node and all of the applications that you attach to it can make use of the entire funds. So, bundled nodes, if you have $50 and $50 on two different applications, you cannot pay 51 unless you take one app, close a channel, transfer funds over, then open your channel and incur a larger reorganization. Whereas the remote node has $100 worth of bitcoin and you can dip into those $100 right away without any issues. And mobility is also an issue, right? If you have funds bound to a node that is bundled with an app, it's really hard for you to try out a different app. Whereas if it's just a front end to a remote node, it's really easy for you to switch out because you don't have to tear down channels, transfer funds, open new channels and just to get a taste of what the system looks like right now.

‍

Kevin Rooke - 00:36:29:

‍

Is this bundle node system, is that common today? What would an example of that set up be?

‍

Christian Decker - 00:36:36:

‍

There's many different attempts to go down that road. Specifically, the noncustodial version of Blue Wallet, for example, has a node bundled inside it. The old Breeze app has an Led node bundled with it and quite a few different applications where you put the entire node code into. The application itself.

‍

Kevin Rooke - 00:37:08:

‍

Got it. And so over time, you think that the transition is going to be from the bundled nodes to the remote nodes?

‍

Christian Decker - 00:37:16:

‍

I think so, yeah.

‍

Kevin Rooke - 00:37:17:

‍

Is that what we've seen with Breeze as well? I think there's an integration with Greenlight, yeah.

‍

Christian Decker - 00:37:23:

‍

So one of the announcements we had in Miami was that Breeze is switching over to our service Greenloid exactly. Because we said, hey, look, I personally am not very good at building front ends. I'm good at working on the specification, implementing the specification and operating a node. But the front end is definitely not my world. So let's concentrate on our specialities and we take on operation of nodes and they work on the front end, the application, added services on top of it. And so by basically specializing, we get more than the sum of the parts, basically.

‍

Kevin Rooke - 00:38:16:

‍

I hope you're enjoying the show so far. I just want to give a quick shout out to our sponsor, Voltage. Voltage is the industry standard for Lightning Network infrastructure, creating layer two applications and services on top of bitcoin starts with Voltage, where you can spin up nodes, get access to liquidity, optimize your node and much more. Voltage is leading the way as the next generation provider of Lightning Network infrastructure. And if you want to get a free trial and start using Voltage today, you can do so at Voltage Cloud. Now, in the announcement post for Greenlight, I believe there was a line that said something like, this is the latest Lightning service to be launched by Blockstream. I'm curious to know what else are you thinking about in terms of Lightning services? What else are you thinking about? The block stream.

‍

Christian Decker - 00:39:09:

‍

So there's a whole slew of added services that we are building as part of Greenlight. I'm not sure I would consider them separate services, but for example, we are planning on working on a reverse proxy that should allow everybody to basically connect to their node without having to configure their router or their access point or stuff like that. We've come out with a service that allows nodes to synchronize with the gossip of the network in a couple of seconds instead of the slowish gossip protocol that we had so far. That system was called Ln Sync and it was a proof of concept. We also attached that to the satellite, by the way, which is really interesting. I got to write some satellite code. Never thought I would be able to say that.

‍

Kevin Rooke - 00:40:13:

‍

What's the use case there with the satellite? Because I think few people know that there's a block stream satellite project, but I don't know offhand, I wouldn't be able to tell you here's exactly why we did satellite.

‍

Christian Decker - 00:40:28:

‍

So the original idea for the satellite was, and still is to bridge an eventual network split. So there are regions of the world that are not very well connected to the Internet or that have intermittent access to the internet. Think of oppressive states that happened to cut off the internet access for a while. There has been an exercise by Russia to basically self isolate from the rest of the world. And that is a huge danger for Bitcoin because if you are sort of isolated from the rest of the network, your network might not make any progress. You won't see any transactions and any transaction you perform will not confirm. Or even worse, then you might see confirmations but you're unaware that in another part of the world there is a longer chain. Using the old longer is better property. Once the split is sort of removed, all of a sudden all of your confirmations go away. And so to prevent that kind of issue. The satellite is there to allow communities that do not have good network connectivity to stay in sync with a Bitcoin network by streaming the expensive large blocks over the satellite dish instead of maybe your meter GPRS connection and to bridge these gaps in communication where you have one part of the network that I split off and you then bridge from the outside into that to basically say hey. Look. You might have gotten a confirmation but there is a longer chain outside of your split. So maybe don't accept it. And so the goal here is to say if I want to send a transaction that's a couple of hundred bytes, I can't transfer that over an SMS, for example. I cannot do so for the blocks. Those are a couple of megabytes and that would be prohibitively expensive to synchronize over a meter connection, basically. So we provide that service to bridge those gaps. And the same is true for Ellen sync where we have where the connection between individual peers is relatively low traffic and so that could be done. For example, I once had it running over an email server, for example, where you could actually see each individual message going back and forth. But there is a part of the communication that is large and that is basically all of the meta information that you need to stay to learn about the structure of the network. Because enlightening you always have to find a path from sender to recipient. And you do that by learning about the, let's call it a street map. And you then sort of walk down individual roads and the succession of roads becomes your route and that's where you send your payment through.

‍

Kevin Rooke - 00:44:06:

‍

Interesting. I want to talk a little bit about Lightning scalability. What are the scalability limitations to the protocol today?

‍

Christian Decker - 00:44:20:

‍

That's interesting because my PhD thesis was on the scalability of Bitcoin and the sort of last chapter was hey look, off chain protocols, we can scale using those. And so Lightning itself was presented as a scalability solution. And it's always important to emphasize here that a scalability solution doesn't mean that we can go infinitely down that road and without incurring any additional hurdles it means that we have unlocked the next step of usage. So maybe you go from ten K users to 10 million users and that is already a huge scalability step. It doesn't mean that we get to a trillion users basically without any additional changes. So when it comes to scalability limits of Lightning there is pretty much one two. One is that each channel that we have enlightening needs an on chain representation. So like I said before, when we open a channel we take some funds and we lock them into a separate part, we freeze it and we do so by creating a multi SIG that is controlled by all of the participants of that channel. So enlightening that's two and the funds cannot be moved unless both parties sign off on what happens with those funds. So opening and closing a channel has an on chain footprint and sometimes that footprint can be large. So Lightning is pretty optimal when it comes to its on chain footprint. We have one open transaction that is I think, 250 bytes and we have a closed transaction that is basically just dependent on the number of outputs. Namely if there aren't any HTLCs attached to it then it's two outputs. Otherwise it might be a bit more. And for unilateral closes that footprint can get quite big. So if a channel gets closed while there are payments being processed then it might be quite expensive to close that channel. So this footprint limits us to a certain number of channels being opened and closed. Each block. At some point there is an equilibrium where we open and close the same number of channels in each block and then we basically hit the limit of the size of the Lightning Network. Where that is, I don't know. That very much depends on the behavior and structure of the network itself as well. So if we get sort of perfect operators that always take care of their channels and every single payment goes through, no payment ever gets stuck, then we can basically open channels infinitely because we end up never closing channels. We can just reuse them over and over again. And the sloppier operators get the less the more channels get closed, the less capacity, the less block is available to open new channels basically. Beyond that there are a couple of proposals that we have out there, namely multiparty channels and similar constructions that instead of going with a two party channel we may open up to a bigger group. So that could be anywhere between three to I think in my last paper I wrote 15 out of 15 people but we definitely can go beyond that now with Schnore and Taproot coming live.

‍

Kevin Rooke - 00:48:51:

‍

Multiparty channels, is that the same as channel factories? Are these different?

‍

Christian Decker - 00:48:55:

‍

Yes. So channel factories are one example of multiparty channels. So channel factories, the idea is to have one big channel and then you sort of split up into smaller channels using those funds. And so you settle the inner channels, you settle onto the outer channel and you can nest them arbitrarily deep.

‍

Kevin Rooke - 00:49:17:

‍

Got it?

‍

Christian Decker - 00:49:17:

‍

And there is, as far as I know, just my two constructions duplex micro payment channels and L two to really build usable multiparty channels.

‍

Kevin Rooke - 00:49:31:

‍

What does multiparty channels do to the structure of the Lightning Network? What changes do you foresee if that is a reality, that everyone is using these multiparted channels?

‍

Christian Decker - 00:49:44:

‍

So with more multi party channels, we end up using the outputs that we have on Chain more efficiently, right. When we create a channel in Lightning, we basically, you and I now share a multisig output that is on Chain, right? And that multisig output can then split up into any number of outputs depending on how we allocate funds. So we might have ten bitcoins in total. That would be one huge channel. But let's stick with round numbers. You own eight bitcoins and I own two. We now agree that we might want to create a third output and that comes from your balance. And so we end up with two, one and seven bitcoins. But since this is all anchored in this one multi SIG, basically this one multi SIG represents these three outputs that we can potentially create. And among ourselves, we can be sure that those will eventually exist after all. Now, if we take a multiparty channel with, let's say, let's not exaggerate ten participants, all of these ten participants basically have certainty that their output will eventually exist on Chain if we agreed upon in the multiparty channel. Furthermore, if I create a two party channel and I'm one participant, then I can basically interact with one other party. If I create a multiparty channel with ten participants and I'm one of them, then I can all of a sudden interact with nine other participants. So it is as if I had created a completely connected graph between all ten participants instead of just one other participant. So not only is the usage of the utility I get from this one multi SIG output that I created on Chain has increased massively, but also the flexibility of who can I interact with using those funds basically, right?

‍

Kevin Rooke - 00:52:13:

‍

Chain footprint smaller and the ability to send and receive from more participants.

‍

Christian Decker - 00:52:20:

‍

Exactly, yeah. Basically, with a ten party MPC, I have the same utility I would have gotten from using nine two party channels, basically. Now, where this all breaks apart a bit is how large do we want these multiparty channels to become? So one trivial idea would be let's all just join one multiparty channel that sadly doesn't really work because it would be great, right? 8 billion people with one multi SIG on Chain and everybody can interact with everybody else. The issue there is that it doesn't really work that way. So there are requirements for you to be online because you have to sign off on any change that happens in this system. And the bigger the group, the higher the probability that one of us isn't there and we can't make progress.

‍

Kevin Rooke - 00:53:22:

‍

Does that change if everyone's hosting their Node in the cloud, there's someone managing that process or no, you have to sign off with the key.

‍

Christian Decker - 00:53:32:

‍

So I would definitely suggest that everybody should still manage their own keys because anything else isn't secure. And as soon as you put basically hundreds of people in charge of their own keys, one of them will probably have some issues.

‍

Kevin Rooke - 00:53:50:

‍

I see.

‍

Christian Decker - 00:53:51:

‍

And so at any point in time, some part of the system might be offline, we as a whole might not be able to make progress, which is the sad part about multi party channels.

‍

Kevin Rooke - 00:54:07:

‍

Got it. What's the roadmap to implementing multiparty channels? What does that look like?

‍

Christian Decker - 00:54:14:

‍

So we've proposed L Two, which is one of the mechanisms that can be used to implement multiparage channels back in 2018. It has since gone through quite a bit of review, and I've been chilling it everywhere. I can so much that most people will shut me up when I start talking about L Two, but it seems to be making progress. One of the things that we need for L Two to become possible or usable is a change in the bitcoin protocol itself, called Seekhash Anyprivout, although there are competing proposals now that could be used as well. And while I'm the author of Seekhash No Input, which is the precursor of Seekhash Anyprivout, I would be okay with any of those proposals as long as I get the functionality needed for L Two. Seekhash Anyprivout looked like a sure thing for a long time until OPC TV came along and then Op TX hash and all of the different covenants proposals. But I'm really happy that sort of this discussion came up again and it is now very active on the mailing list as well. And so we seem to be making progress there, and I'm optimistic that we will get one of these solutions eventually. In the meantime, Greg Sanders, another block streamer, is working on implementing L Two on the liquid side chain, which, like I said before, is basically our experimental side chain that we can use to experiment on future innovations for Bitcoin, where we can make these learnings and then backport them into bitcoin itself or propose them to the bitcoin maintainers. So things are looking good that we will have a working proof of concept eventually on liquid.

‍

Kevin Rooke - 00:56:39:

‍

Got it. Eventually, the progress of multiparty channels depends on at least one of these solutions being implemented on the bitcoin protocol, is that correct?

‍

Christian Decker - 00:56:54:

‍

Either that or we can come up with alternative constructions. I mean, there is ongoing research into all of this and I'm pretty sure that there are clever minds out there that can, with the tools that are already available, build something that is very close, if not better than L two. The challenge is basically to everybody find a way for us to make the most efficient use of this scarce resource, namely the blockchain. Right. Mine is only one of the solutions there. Basically. That being said, there is a poor man's version of L Two that we could implement right now. I call it a poor man's version because it has messages that increase linearly with the number of updates. So probably not what you want to use for channels that are open indefinitely, but you can use it for experimentation already.

‍

Kevin Rooke - 00:58:06:

‍

One thing you mentioned a little while ago is like the possibility that we get to a point where people just don't close channels. Is that realistic, do you think, for routing node operators to just never that we can basically communicate between nodes in a way that makes it so that you just don't have to continually close channels.

‍

Christian Decker - 00:58:29:

‍

So it's probably a good topic for the entire network as a whole to expect not to open and close channels because our social structure changes as well. Right. I might have kids someday that I want to inherit my bitcoins to and if there's more than one, I will have to close my node and sort of split the funds apart and they will have to open a new node and fund channels. But for routing nodes it might be possible that they never have to close channels simply because they have a tendency of optimizing their position in the network such that the traffic they see is relatively balanced. And so they maximize the use they can get out of a channel being created by positioning them such that funds go both directions in roughly the same amount. And that means that a channel will never exhaust and can be used indefinitely. So I wouldn't say as a whole network we want open and closed channels, but we can end up in a situation where the core routing network is very very stable. And the utility that a routing operator gets from his two on chain transactions, the open and the close for a channel can potentially be infinite simply by keeping the channel open as long as possible.

‍

Kevin Rooke - 01:00:13:

‍

And as we progress towards that, does that also make Lightning more scalable and able to onboard more people? Is that the idea?

‍

Christian Decker - 01:00:24:

‍

It definitely makes it more stable. So the more stable the core network is, the more balanced the channels are, the better we can predict what happens inside of that core network, the better we can make sure that when we try a payment, the higher the probability of it succeeding. And of course a channel that has just been closed will have users still trying to route through that node because they haven't seen it, or a channel that has just been opened might not be in the map of the nodes trying to make a payment. So the more stable the core channels are, the more stable our payments are that go over those channels. As for scalability, I'm not so sure. Like I said, on the edges of the network, we will definitely see a lot of opening and closing simply because these end users have a tendency of not having really long term relationships between their providers and their wallets and what have you. Not so think about how often people change their mobile carrier. Each of those would be a channel close and channel open if we were to make the similarity between mobile carriers and Lightning, node LSPs and stuff like that. As for scalability, it's mostly those end user traffic on chain that will limit our scalability. And the core network that is mostly stable is basically an offset that acts as a basis for the rest of the users, basically.

‍

Kevin Rooke - 01:02:29:

‍

Got it? Now, what role do things like peer swap and Liquidity Ads have in this stabilizing and scaling the Lightning Network?

‍

Christian Decker - 01:02:41:

‍

So, Liquidity App is a proposal by Lisa Nagat, and she came up with a system where you can basically advertise that you would put some make some liquidity available for users that are looking for incoming channels. And so this addresses basically the issue of a new user joining the network. And the usual thing that the users will start doing is by basically sending your friend who you just onboarded, you'll send them a couple of Satoshis. And the problem with that is that a newly joined user does not have any incoming channels and doesn't have any capacity going towards them. And so before you can even show your friend, hey, look how cool this is, I just sent you some Satoshis, you have to somehow get them to receive an incoming channel so that you can then do your cool demonstration. And Liquidity Ads is basically this service where a wallet, either automatically or on request by the user, could collect all of these Liquidity Ads, which are gossip in the network, gossip, which is also what we use to basically build up our image of what the network looks like. And in there, there are proposals for channels to be open to you. You then pick out one of the offers that sounds interesting to you. That could be, for example, pay me 10,000 Satoshis, I will open a channel with 250,000 Satoshis, and I would promise I will keep it open for two months and I will not charge more than X fees. You basically then select one of these ads, you contact the node, you say, hey, I'd like to take you up on the offer here that you broadcast. And they will say, okay, let's start a funding between the two of us. And you can then open a channel, have some incoming liquidity, and then your friend can send you your Satoshi for the cool demonstration.

‍

Kevin Rooke - 01:05:09:

‍

Got it? And then also peer swap.

‍

Christian Decker - 01:05:13:

‍

Yeah. So Liquidity Ads is a way for us to onboard new users. Peer swap is a mechanism for us to make the most of our channels. So as many Lightning operators will have noticed, there is quite a bit of work going into maintaining the balances of your channels. Namely, if you open a channel then that channel is most likely only has outgoing capacity. If you received an incoming channel that will only have capacity on the side of your peer. And to sort of come true to the expectation that there is some liquidity to forward payments, you have to now rebalance the channel. One of the techniques that many people have used is what's called a circular rebalance. So what you do is you pay yourself but through the channel you're trying to rebalance over some outside nodes and then back through a different channel to yourself. What that does is basically if you have one bitcoin outgoing on one channel and one bitcoin incoming on another channel. You can send out half of that bitcoin through the first channel back to you on the second channel and you now have half a bitcoin on one side. Half a bitcoin on the other side and this and both channels this maximizes the chances of you forwarding a payment. The problem of that is that you also just unbalance a lot of channels that weren't yours. Because to get from your nodes through one channel and back into your node through another channel, you had to go through somebody else and maybe you just unbalanced their channels and their next action might be oh, I'm going to rebalance that back. Your own actions basically are causing the reaction that undoes your action. And the idea behind peer swap is but why are we doing that? So instead of going through different channels, what peer swap does is basically tell your direct peer hey, I want to rebalance this channel. Are you okay with sending me the funds on chain? So you send half a bitcoin over that channel and you receive half a bitcoin on chain back to yourself. Got it? All of this without interrupting any other node, without causing them additional traffic, without all of the failed rebalance attempts that we often see. And many databases are now overflowing probably because some people are rebalancing excessively. So peer shop is a solution for us to balance our channels and just our channels.

‍

Kevin Rooke - 01:08:12:

‍

So these two solutions sound a lot like on the LND side, Lightning loop and Lightning pool. Is that a fair comparison to make?

‍

Christian Decker - 01:08:24:

‍

The difference is that we are not relying on one instance of this liquidity ads. Everybody is free to basically publish liquidity ads and at the same time everybody can be a peer swap peer. So we are basically making everybody the equivalent of a Lightning loop and a Lightning pool without getting our share. We aren't charging for that. It's a more democratic system because everybody can basically offer this service hey, I'd like to offer some channels to my fellow Lightning users. Why do I need to have a coordination instance at all, if I can just talk peer to peer with my potential customers.

‍

Kevin Rooke - 01:09:19:

‍

Got it. But more or less solving the same use cases in a different mechanism, right?

‍

Christian Decker - 01:09:25:

‍

Yeah. I mean, they are addressing an issue and we approach those issues slightly differently and we hope that we are solving those issues for our users in the same way. Basically.

‍

Kevin Rooke - 01:09:43:

‍

We've also seen other liquidity marketplaces pop up recently. One is Amboss released Magma, and that seems to be more comparable to Lightning Pool or Liquidity Ads. Do you expect to see more marketplaces pop up for things that resemble peer swap or Lightning loop?

‍

Christian Decker - 01:10:12:

‍

I definitely think that there will be quite a bit of competition around these sort of closed environments like loop and pool because you can make some money out of it. Right. You are the coordinator and so you can leverage a fee. The thing that we tried with Pure Swap and with Liquidity Adds is to basically sidestep that wall garden issue by saying, hey, we have a shared system that everybody can advertise on, everybody can offer their services without any intermediaries. And so I hope we sort of made the walled gardens superfluous. But I do see, I definitely see a need for interfaces to be built on top of it. Basically the Lightning Network explorers that expose Liquidity Ads and stuff like that. So I do see that need, but I don't think that any sort of walled garden system is going to survive long term.

‍

Kevin Rooke - 01:11:31:

‍

So do you think that's true then, across the Lightning Network that there will be no venue for companies to capture value in the same way that there is for maybe Web Two or the Internet today? Do you think that over time we kind of get past this idea that some company can control a marketplace?

‍

Christian Decker - 01:11:54:

‍

So I think that should definitely always be our goal. One of the attractions that got me very interested in Bitcoin is that everybody can be their own bank, right? That used to be the big thing. But you don't have to be your own bank as a user can choose your own risk profile. You as a user can choose to invest the time to learn and to experience and to reduce your reliance on third parties. Many people will choose to rely on third parties and that should be fine, but the optionality has to be there. Right. I have to have the option of digging in and really learning and taking on responsibility, but also the freedom that I get from adopting Bitcoin and adopting Lightning. I would be really sad if that option were to be taken away from me.

‍

Kevin Rooke - 01:12:55:

‍

Right.

‍

Christian Decker - 01:12:56:

‍

So I think any sort of capture must not succeed because that is then a part of the ecosystem that can be corrupted and that has a different access than I, as in Andrew, individual user can have. And so that for me would pretty much yeah, it would be frustrating, right, because the ethos of Bitcoin and Lightning is that I can take on all the roles that were taken on by intermediaries before, and if we now just create new intermediaries, what's the point?

‍

Kevin Rooke - 01:13:45:

‍

And there's, I guess, attention there, because network effects also play a role here, right? As any community grows large enough, it just becomes so compelling to use that product or that service because of the network effect. Do you worry at all that the network effects in closed ecosystems could overpower or convince people to use those ecosystems without considering the fact that they don't have full interoperability with the rest of the network?

‍

Christian Decker - 01:14:25:

‍

So we definitely should be making noise whenever these sort of large participants decide to deviate from the public protocol simply because that is what keeps everybody on the level playing field. And I do see that many people will choose to go through intermediaries, maybe have a custodial wallet and maybe have their node hosted by somebody else simply because that is their choice and we should be okay with it. We cannot force users to invest the time and learn about how to run a Lightning node, for example, right? That's a major time investment. And who are we to tell them that they have to do it? So we shouldn't get angry at users that choose to go through these intermediaries because they do offer a service, they do offer usability and ease of use, basically. But we should keep the operators of those services accountable whenever they deviate from the agreed upon standards simply because they try to sort of build a wall around their ecosystem. And if that were to happen, I would hope that users would rebel against that and leave those platforms that decide to become malicious and join the wider open network.

‍

Kevin Rooke - 01:16:07:

‍

Yeah, I agree, that makes a lot of sense. I know we're running out of time here, but I want to jump into a segment that I do at the end of every show called the Lightning Round, where listeners can send in questions over the Lightning Network. We had a few questions come in from listeners yesterday. So are you ready for the Lightning Round?

‍

Christian Decker - 01:16:28:

‍

Absolutely.

‍

Kevin Rooke - 01:16:29:

‍

Welcome to the Lightning Round, presented by Zebedee, your portal into the world of bitcoin gaming. The Zebedee app offers a full featured Lightning wallet, seamlessly integrated with your own personal gamer tag so that you can earn bitcoin on all of Zebedee's games on mobile and desktop. It's never been more fun to earn bitcoin, and Zebedee is your key to it all, to claim your personal game or tag and start earning some bitcoin of your own. Download the Zebedee app today first question comes of your own. Download the Zebedee app today first question comes in. Actually, we had three questions, all from from the same user Urza. CC asks, what are you most excited about, both in general for Life and in regards to Lightning and CLN?

‍

Christian Decker - 01:17:20:

‍

There's so much going on, I can't pare it. Down to a couple much going on, I can't pare it. Down to a couple of things. Generally speaking, the excitement, the sort of exploratory nature that we have in the Lightning specification and in all of the implementation is what keeps me interested and gets me out of bed every day. And I really look forward to that. Staying the same or becoming better even. So it is really this community that gets you up and going in the morning.

‍

Kevin Rooke - 01:18:02:

‍

Love it. The other question, second question was what does your CLN node set up look like? What database configuration plugins and tools do you use?

‍

Christian Decker - 01:18:15:

‍

Oh my, that's a long list. So I had an experimental node from a company called Shift Crypto here in Switzerland. They were building a node in a box using CLN, and I got an experimental version of that. Sadly, that node never made it to the public, but it has been running in the background of my office for the last four years without any issues. So I haven't built it myself, I'm afraid to say, but I had to customize it a lot. So there's definitely a couple of plugins running on there. There's the summary plugin, there's the rebalance plugin, there's the backup plugin, which I've been promising to improve for the longest time now that I remember. There's a chat protocol client on there. Basically the key send, what's it called, WhatsApp client? Which I reverse engineer it and re implement it, and some probing plugins because I wanted to have some good numbers on the reliability of payments in the Lightning Network. I think that's probably the most important ones. There's also a plugin I use to test MPP implementations using Renee Pay. So lots of experimental stuff going on there.

‍

Kevin Rooke - 01:19:46:

‍

Got it. Final question from Urza_CC is you're going to actually have to give me a little background on this because I don't exactly know what the Commando plugin is. But Urza_CC wants to know what are some good use cases for the Commando plugin?

‍

Christian Decker - 01:20:02:

‍

So the Commando plugin is a plugin that Rusty has built, and I'm afraid I'm terrible at naming. And so the name came from me, it came from an Arnold Schwarzenegger movie. And the idea is, basically we have a number of ways to interact with a CLN node. That is the JSON RPC, there is a Rest API, there's a gRPC API, and so on and so forth. But all of these were basically non Lightning native ways to talk to your node. And Commando uses the Lightning Network protocol itself to control your Lightning node. Instead of having to open two ports in your firewall, you open one. And it works the same way. You already have a tour configured for your Lightning node. We use that connection for your Commando connection. And using the Commando connection, you can then have access to the programming interface. So you could, for example, have a Lightning wallet that natively speaks the Lightning protocol, talk to your node through the Commander plug in is that similar to.

‍

Kevin Rooke - 01:21:26:

‍

Ln Link and Ln socket?

‍

Christian Decker - 01:21:30:

‍

I'm not familiar with Ln link.

‍

Kevin Rooke - 01:21:34:

‍

I think it's just like a mobile interface for connecting with your node remotely.

‍

Christian Decker - 01:21:39:

‍

Is that by JB 55 yes. Yes, it is. Using Commando underneath it.

‍

Kevin Rooke - 01:21:46:

‍

Got it. Interesting. Okay, I got a few more questions for you. Kind of rapid firestyle here. How many people will be running a Lightning node in a decade?

‍

Christian Decker - 01:22:03:

‍

Just a caveat. I'm terrible at predicting stuff. Just as a reference point, I sold my first bitcoins at $0.05 each, so don't trust my predictions. I would be saying which year?

‍

Kevin Rooke - 01:22:26:

‍

A decade from now? So actually, let's say 2030, just for round numbers.

‍

Christian Decker - 01:22:30:

‍

2035 to 6 million users.

‍

Kevin Rooke - 01:22:36:

‍

People running a Lightning node. Five to 6 million?

‍

Christian Decker - 01:22:38:

‍

Yeah. Not users. Those are just the nodes running in the network.

‍

Kevin Rooke - 01:22:44:

‍

I like it. How much public capacity will be on the Lightning Network in 2030?

‍

Christian Decker - 01:22:51:

‍

Q, evil grain? All of it. No idea. I don't have any idea what coins might be worth in a decade. So it's kind of at least two estimations in that one question, which I don't feel comfortable saying.

‍

Kevin Rooke - 01:23:14:

‍

Fair enough. If you could change one thing about Bitcoin, what would you change?

‍

Christian Decker - 01:23:20:

‍

One thing about Bitcoin that I could change. It's called a Lightning round, but I'm drawing a blank. Probably I would have enabled to cash any private already. That's a very selfish answer, but the more honest answer would be I wouldn't change anything.

‍

Kevin Rooke - 01:23:49:

‍

Fair enough.

‍

Christian Decker - 01:23:50:

‍

I do like the set up. At least I wouldn't change anything on the technical side. I might want to change some parts of the community. What party does? Way less scammy behavior from many people.

‍

Kevin Rooke - 01:24:07:

‍

Fair enough.

‍

Christian Decker - 01:24:08:

‍

And much more serious and honest discussions about things.

‍

Kevin Rooke - 01:24:14:

‍

I like it. What are your favorite Lightning apps to use? Do you have any on your phone like that you use regularly?

‍

Christian Decker - 01:24:23:

‍

I don't have one on my phone. I'm almost always using the command line. So Lightning CLI, that is the app to go. Or with Greenlight, there is GL CLI, which app to go. Or with Greenlight, there is GL CLI, which I'm also using a lot. Like I said, I'm really bad with front end, so I tend to stick to my trusty shell.

‍

Kevin Rooke - 01:24:44:

‍

Got it. But you haven't experimented with any of the user facing applications like the news and things like that?

‍

Christian Decker - 01:24:54:

‍

I've used the Sphinx chat app. I've used Spark. Zeus is a very good front end RTL. Of course, RTL is really good looking and it's actually running on my node, too. Why didn't I mention that one? So there's a couple of front ends that I do enjoy using. I'm also currently porting Spark over to greenlight, so I might eventually have used that with green light on my phone again, which would be really cool because I get to pay for tacos again using my phone.

‍

Kevin Rooke - 01:25:31:

‍

Final question. Are there any books that have meaningfully changed your view of the world?

‍

Christian Decker - 01:25:38:

‍

Books that have changed the view of the world. Not a huge reader, so I will have to say Harry Potter.

‍

Kevin Rooke - 01:25:52:

‍

Hey, I like it. Good choice.

‍

Christian Decker - 01:25:54:

‍

There used to be a time where everybody in bitcoin was into Harry Potter, and I think I might still be stuck in those times.

‍

Kevin Rooke - 01:26:02:

‍

Really? This must have been before my time.

‍

Christian Decker - 01:26:06:

‍

Yeah, no, I mean the whole bitcoin wizards channels comes from that. The whole Nimble Wimble team is basically made up only of Harry Potter characters. So, yeah, they're definitely made up only of Harry Potter characters. So, yeah, they're definitely is a huge Lord of the Rings Harry Potter influence in the early bitcoin days, at least.

‍

Kevin Rooke - 01:26:33:

‍

Interesting. So that's that bitcoin wizard, the magic internet money. The wizard is tied to Harry Potter somewhat or no.

‍

Christian Decker - 01:26:39:

‍

Wow.

‍

Kevin Rooke - 01:26:40:

‍

Interesting. I didn't know that. All right, well, that's it. That's it for today. Thank you so much for the time. I thoroughly enjoyed the conversation. I'm sure listeners will as well. Where can people go to learn more about you and the work you do?

‍

Christian Decker - 01:26:54:

‍

So I'm on Twitter, snyke, snyke and everywhere else. So GitHub everywhere I'm Cdecker.

‍

Kevin Rooke - 01:27:06:

‍

Perfect.

‍

Christian Decker - 01:27:08:

‍

So if there is something, just reach out, I'll make sure to answer.

‍

Kevin Rooke - 01:27:13:

‍

Cool. Thanks for taking the time and I hope we can do it again soon.

‍

Christian Decker - 01:27:17:

‍

Thank you so much for having me. It was a lot of fun.

‍