Lightning Network Devs Discuss the Future of Sovereign Computing
Leading Bitcoin Lightning Network developers recently discussed the future of this Layer 2 protocol.
Listen:
Lightning Network channel capacity is increasing rapidly, reaching a new all-time high of over 2,900 bitcoin recently. But there is a whole lot that goes into running a node on the Lightning Network, with many different techniques and ways to optimize.
In a recent Twitter Spaces conversation hosted by Bitcoin Magazine, Lightning Network developer Thomas Jestopher described how rebalancing is a big part of managing a Lightning node and routing payments. Specifically, he described his technique for circular rebalancing.
“I tend to describe circular rebalancing as choosing who you want to send through, which nodes you want to send through and which nodes you want to receive through,” he said. “Typically, I like to receive through my best, connected nodes. Those are the ones that have a whole bunch of channels and that are large channels. That makes it so that I could receive from a large portion of the network. Then, my sending capacity, I might choose to send through some smaller nodes. They usually appreciate the inbound liquidity that I would be providing to them from my well-connected node.”
The Spaces also covered some issues to watch out for when running a Lightning node. For instance, a potential issue with privacy on the Lightning Network could stem from irresponsible or excessive “probing,” a way to discover channel balances.
“You are getting the traffic from somewhere and you don't know where it's coming from,” said Alex Bosworth, the infrastructure lead at Lightning Network development firm Lightning Labs. “If you rate limit it, you're just rate limiting everybody. That actually makes the problem worse, because now, you've just increased the bang for the buck of doing an abuse. You basically shut off the node. I think there are a lot of solutions for how this could be solved, but it does need to be prioritized. People need to be talking about this more, maybe than other things that they're working on, adding to the spec that are not thinking about how to harden the network.”
The speakers also discussed new tools that are being developed in order to onboard millions and eventually billions of people onto Lightning, one of which is sidecar channels — a Lightning Pool feature that lets someone access Lightning without a commitment of funds.
“The way that I understand sidecar channels right now is that it just requires that the person purchasing the channel lease does not have to be the one who receives the inbound liquidity from the channel lease,” added Keagan McClellan, the cofounder of Start9, which offers servers for running self-hosted software and easy installation of the Lightning Network. “I think, that that's the only difference. What that would mean is that it basically just functions as a normal channel, but it doesn't require someone to have Bitcoin loaded up into a bunch of different wallets to begin with.”
The full recording of this Spaces conversation includes many more details and much more discussion. To read the whole conversation, check out the unedited transcript below:
[00:00:06] P: Why don't we start off? Keagan, do you want to give a brief introduction to who you are and what you are working on?
[00:00:13] KM: Yeah. Yeah, my name's Keagan, I am one of the co-founders of Start9 Labs. In the context of this discussion, we built something similar to Umbrel, where we are building a server product to make these various applications one-click installs. That's what I do for work.
More broadly, I've been a Bitcoiner for, I don't know, four-ish years now in terms of, on the dev side, and then as a user for another two years beyond that. I actually got into Bitcoin dev, because I took trust, don't verify a little too seriously. People would say things about how Bitcoin worked and I'd ask the question, “Is that actually how it works?” Most of the time, the answer was yes, but occasionally, the answer was no. I just kept doing that. Now, I do that for Lightning, instead of the layer one consensus stuff. Yeah, endlessly trying to dive deeper and learn new stuff all the time. It turns out, this stuff is enormously complicated.
[00:01:08] P: Fantastic. Yeah. I love it. Severin, you want to give us a brief intro and talk about the incredible website that you've created?
[00:01:16] SA: Yes. Hi. Very good morning. I'm Severin. I'm the creator of LnRouter. LnRouter is a tool to help routing nodes to get insights in their node and to get insights into the whole network. That is the goal of LnRouter. I started to create LnRouter in January. Around January. Yeah. It was just created out of the need, because I wanted to start my own routing node. I had no idea what I was doing, because the Lightning Network is basically a black box, if you start out with the Lightning Network. You have no idea where to connect to. You have no idea what the metrics matter in the Lightning Network. Then you're just there and you connect to a node and nothing happens. You don't see any traffic. Yeah. LnRouter is a website that I created to solve this. It's nowhere near I want it to be, but I'm still working on – I believe, there are a lot of cool things coming in the future.
[00:02:19] P: Yeah. Yeah, absolutely. LnRouter is an incredible tool. When did you release it, the original version?
[00:02:24] SA: I bought the domain in April. I just looked it up yesterday. The first version was probably up in May or so. Yeah, there are tools coming all the time, as long as I have time to program on it.
[00:02:34] P: Yeah. It's definitely one of the newer tools that has fundamentally shifted my understanding of the network in a really positive way. Jestopher, you want to jump in and give us a brief intro to who you are and what you've built?
[00:02:44] TJ: Sure. Yeah. Thanks for having me on. Yeah, let's see. I started off in Lightning just as a pleb, playing with a raspy blitz as a quarantine hobby. Really fell in love with it. Was trying out some of the new apps, including ThunderHub. What I'm working on now is called amboss.space. It is a Lightning Network Explorer. I'm working with Tony IOI, or you might know him better as AP on telegram. He's the developer behind ThunderHub. We teamed up, so using my knowledge as a routing node operator and Tony's incredible work as a front-end developer to create a Lightning Network Explorer that's built for routing nodes. We're continuing to build out tools for just to help out the Lightning ecosystem and give and provide good data and actionable insights for routing nodes.
[00:03:38] P: Yeah. Yeah. It's a really exciting time to be in Lightning. I think, just for the audience, what we're talking about here is Bitcoin is a layer one technology. It's sound money. It's incredibly important. On top of it, there are what are called layer two protocols. The Lightning Network is built on top of Bitcoin. It allows you to transmit Bitcoin, essentially instantaneously, and for very low fees.
When you hear people say, “Oh, you can't buy a coffee with Bitcoin.” Totally not true. You can totally do it on the Lightning Network today. That's what we're talking about just for a little more context. Everyone who’s a speaker has, with the exception of me, has created really amazing tools that that help us build up the network further by empowering people like me, like others, people in – which is this community that we got together and started to help us all understand Lightning and learn how to be effective routing nodes in the network, because there are three different types, or let's say, very broadly speaking, there are three different types of users of the network. This is how I think about it.
There's a person who basically wants to just whip up open their phone and pay someone, essentially instantaneously, basically for free over the Lightning Network. You can do that. Anyone in the audience today, you can just go and download Wallet of Satoshi, or if you want a solution that lets you have full custody of your funds, you can use Breeze Wallet. You can do that today and you don't have to understand anything about the wiring of how it works.
Then there's people who want to be merchants. They're basically selling a service and they want to be able to accept Bitcoin over the Lightning Network for that reason. They can use things like, Breeze Wallet, which you can download, has a point of sale feature, but ultimately, a lot of merchants end up running their own Lightning nodes.
Then, the third extreme is what all of us are doing, which is not only are we participating in Lightning Network, but we actually are running nodes that allow payments to be routed through them, because that's the way the Lightning Network works. Just because I don't have a connection directly to some person, whoever they are, I can bounce payments through other nodes in order to get to them and pay them, or receive from them.
When we're talking about all this stuff, I like to be clear that you don't need to be as obsessed with all these, all the nitty-gritty details as we are in order to benefit from and participate in the Lightning Network. Yeah, there's so much interesting stuff happening in it right now. I think, everyone on the stage is, or everyone that's speaking is part of PlebNet, which a bunch of us are deeply excited about. As of right now, I think we're about 3% of the entire Lightning Network in terms of number of active nodes, which is which is really interesting. As we've as we've been building that out and understanding the how to be an effective routing node, the tools that y'all have built and contribute to have really helped do that.
I'm curious, Jestopher, what led to you building out amboss.space, because that's an essential part of my workflow as I go to – whenever I'm evaluating potential peers, potential nodes to open channels to, I check out Amboss as part that workflow. What drove you to that and how did that come about?
[00:06:36] TJ: Sure. Hopefully, we can get Severin back up on stage. Let's see, what we started off actually designing a node manager program. We were focusing it on some specialized tools, where people are managing multiple nodes. We ran into some, I guess, some issues with licensing. If we wanted to make this thing open source, it's really hard to build a business around it. Things like, Ride the Lightning and ThunderHub, they're both struggling to build a sustainable business. These are our critical tools. Now, unfortunately they have to be open source. That's a difficult thing to protect. I know, there's been lots of history with, Umbrel following that story, not to get too deep into the weeds about it. In going through that process and forming a company, we recognized, there's a real need for good information about the Lightning Network.
I think, the tool up until this point has been a 1ML, and we saw a real need to bring all of that information that the Lightning Network provides and create a one-stop shop for people that want to find out the information, as far as routing fees and who these people are to start opening up those lines of communication, so we can coordinate this Lightning Network and this market around liquidity. A big part of that is just getting people to talk to each other. We made the login process very simple. We don't need to require you to open a channel, or get any information from you really. All you would need to do is sign a message using your node and signing a message proves to us that you own that node.
Then, you would be able to customize your page and provide contact information. You'll be able to start talking to other node operators and start coordinating liquidity and allocating it in good spots to give you a return on your investment, when you're putting your savings out on the Lightning Network.
[00:08:36] P: Yeah, it makes sense. Makes sense. Yeah, it's so interesting that there aren't any other services, or aren't any websites that aggregate that information in the same way that amboss.space does. Yeah, I guess I'm curious. I have started running a little routing node in the period after Amboss was created. I'm curious how people got a sense for the fees of all of the nodes without that tool. Obviously, you can – I just don't think there is anything like that out there.
[00:09:02] KM: You can grind through it on 1ML, but it's not as good.
[00:09:07] P: Yeah. Yeah. As a random aside, it's hilarious to me that 1ML, their node, it's a garbage node. Never valid. It doesn't seem like, they ever balanced their channels.
[00:09:14] KM: Well, I don't know that they can. Consider this, in many cases, a lot of these companies that have these massive nodes, at least async “earned” one of their spots in the top. Things like 1ML, they basically took the popularity of 1ml.com to try to translate it into getting people to connect to their node. It was wildly successful in that regard. A lot of people didn't know who to connect to, but they were like, “Hey, there's this tool that I'm using to figure out how to connect to other people. Why don't I just connect to their node?”
It turns out that if you have an enormous amount of inbound liquidity and comparatively little outbound liquidity, the odds that the route that you're trying is going to succeed is astronomically low.
[00:09:55] P: Yeah. Yeah. That does make sense.
[00:09:57] TJ: Actually, to give them some credit and Keagan, you might be able to help fill in the gaps here. One thing that 1ML did that was really smart is actually require users to open channels, because they would get a better source of information about the network as a whole. For example, Amboss currently only has two channels. That affects our ability to see the entire graph.
Now, as our user base grows, I'm sure we'll get more channels opened, and so then, we'll have better visibility onto all of the nodes that are present. I'm sure, everyone can go at ham on the consequences of having that many channels open and having, yeah, essentially, that liquidity in those channels, in tiny channels.
[00:10:43] KM: The thing is, though, is you don't need to have a lot of channels in order to have a complete view of the network graph. The gossip protocol is a peer level thing and not a channel relationship thing. You can receive gossip messages from all sorts of peers and you don't actually have to open a channel to appear in order to have that peer persistently be connected to.
My recommendation is that you should see if just adding a whole bunch more peers without adding a whole bunch more channel relationships to Amboss fixes your problem of incomplete network traps.
[00:11:13] P: Yeah. How would you know if you had an incomplete network graph?
[00:11:16] KM: You can't ever know.
[00:11:19] P: Great. I just want to say, I've attempted to invite several of the people in the audience up on stage. I don't know if you've received them, but NDK, openams, CJ, Walton, KP, Richard, if you if you want to come up, request to speak and we'd love to have you up here.
[00:11:32] SA: Just one input before we continue on here, it's like, connecting to 1ML, connecting to a node that has a lot of channels and a lot of exhausted checklists. It's actually even counter-productive for you to some extent, because the pathfinding algorithm, when you send a payment, will take way longer than otherwise, because it needs to try out a lot of routes that are just not working. Connecting to such a node is really not that good of an idea. If you are only connected to one such node, it's not a big of a problem, but if you're connected to several of such nodes, then your pathfinding is getting slower, especially when this specific node has very low fee, so to pass on the algorithm actually tries this specific node, or all, perhaps, from the specific node.
[00:12:28] P: Oh, interesting. Wait, so just to repeat back to make sure I'm tracking, you're saying that by connecting, if you open a channel to 1ML, you actually decrease the efficiency of your node, because every time you try to find a path through the network, you're going to basically be scanning that node’s gazillion connections, even though none of them will actually be able to route.
[00:12:46] KM: This only applies to you if you're the sender, because all routes in the Lightning Network are source constructed. As a routing node, you actually have no impact on what route is chosen. If you're just routing, it actually doesn't matter as much, other than the fact that it’s just dead weight capital. Ut won't really affect you as a router.
[00:13:04] SA: Yup, exactly. It's when you send payments. It really depends on how the fees are constructed. If this specific node has only one PPM fees, then yeah, half probably. It's not like, that it takes 10 seconds suddenly, again. It takes a little bit more.
[00:13:22] P: Keagan, you said it was applied to people sending payments. Would it also apply to nodes that are trying to do rebalancing?
[00:13:29] KM: Circular. Yeah. Actually, all rebalancing pretty much, with the exception of perhaps a loop in, although I question the times that a loop in is ever viable. That's just because if you are looping in to rebalance your channels, the sender in that regard is the loop server, or whoever your submarine swap provider is, and so you're not exposed to it in that way.
It's not like, it won't have any impact, because if you're connected to something like 1ML and someone's trying to send something to you, it will still appear in the route backwards. Depending on how expensive the route is to 1ML from their point of view, they might still try it. Circular rebalances, you’re both the sender and the receiver, so that's a definite yes on that front.
[00:14:10] P: Yeah. Just for everyone in the audience, when we're talking about rebalancing, or balancing channels, what we're talking about is in Lightning Network, you have a node that's running one of the Lightning implementations. The most popular ones are LND, Éclair, C-Lightning. Basically, you create a channel between yourself and another node in the network. When you do that, what that actually is it's a two of two multisig contract. Well, it's a smart contract. When people say, “Oh, there's no such thing as smart contracts on Bitcoin,” they're just factually incorrect.
Basically, that channel has a bunch of liquidity locked up in it. If Keagan and I open a 10 million SAT channel, and we do it in a balanced fashion, there's 5 million SATS on his side, 5 million SATS on my side. Then basically, we can both send each other SATS. More importantly, payments can actually be routed through that channel over the network. When that happens, if you're running a routing node, you collect a small fee for that service.
When we talk about circular rebalancing, it's where you basically send payments out through one channel and then you receive them back in through another channel, so your net liquidity, your net balance stays the same minus fees. What you do is you basically, shift your channel balances back to being in the middle. The reason that's important is because, it allows you to route payments in both directions.
[00:15:22] TJ: Yeah. I tend to describe circular rebalancing as choosing who you want to send through, which nodes you want to send through and which nodes you want to receive through. Typically, I like to receive through my best, connected nodes. Those are the ones that that have a whole bunch of channels and that are large channels. That makes it, so that I could receive from a large portion of the network. Then, my sending capacity, I might choose to send through some smaller nodes. They usually appreciate the inbound liquidity that I would be providing to them from my well-connected node.
[00:16:01] KM: Sorry. Did you say that you tried to send through the smaller nodes?
[00:16:04] TJ: Yeah, generally.
[00:16:05] KM: If you do that, you're creating outbound liquidity for them to you. You're creating inbound on the other side.
[00:16:12] TJ: Yeah. I'm creating inbound as liquidity for those smaller nodes. Yeah, the terminology is a little confusing, right?
[00:16:22] KM: Okay. The inbound liquidity and outbound liquidity is conserved across payments, with an asterisk, right? Obviously, if you are charging any fees at all, you are earning slightly more in fees than you're dispensing out the other side. Technically speaking, any payment through a node is going to turn a tiny amount of its inbound liquidity into outbound liquidity. You're not actually creating net inbound liquidity for those nodes, but you are reducing the inbound liquidity they have from you and allocating it to wherever the exit point is through that node.
[00:16:55] TJ: That's a good point. Yeah, because circular rebalances, they don't create, or destroy any liquidity per se. It's really just moving it around. It's a question of, who do I want to receive from, and who do I want to send through? Yeah. Good point. I'm not creating any inbound liquidity for them. I'm really making myself the route through which they could receive some payments.
[00:17:16] KM: Just another nitpick, though. If you were sending through the small channels, that means that they used to have inbound liquidity from you. By sending through them, your channel from their perspective is filling up with outbound liquidity. It's actually depleting their inbound liquidity from you when you send through them.
[00:17:34] P: One, I think, is in a slightly different direction. That's all right. Actually, do you want to respond to that?
[00:17:39] TJ: Yeah, I'm getting a little bit lost in the weeds on what you're trying to get at Keagan. Yeah, as a routing node, you want to position yourself to be able to receive from lots of nodes on the network. If you are doing circular rebalancing, you are going to be shifting around other people's liquidity on who they're going to be receiving from, or sending through.
[00:17:59] KM: Yeah. This is also why if you're not a routing node, you should prefer to open your channels private to whatever routing service providers you want to use, so that your liquidity isn't reallocated without your knowledge based off of the needs of the routing network as a whole. Not only that, but it also improves pathfinding for everyone else. Unless you're actually getting solid earnings, then it's probably not going to be worth it to open public channels, when you would otherwise just be a user.
[00:18:27] P: Wait, can you repeat that?
[00:18:29] KM: Yeah. Okay. There are two types of channels in the Lightning graph. There's the public ones, which are basically public infrastructure. That's the routing nodes are all advertising their channels, so that you can route through them, so that you can get your payments to their destinations without you having to have direct channel relationships with everybody, with whom you transact.
However, one of the consequences of that is that, by and large, unless you have specific tooling you've set up for this, any route any requests to route a payment over your channels will be satisfied, or your node will acquiesce to that request. What that will do is it will shift the liquidity between your channels. If you have channels that you wanted to have good inbound from and good outbounds to, because you've decided that's what you want. For whatever reason, the routing nodes on the network have decided that they could benefit from reallocating the liquidity, the other direction, you will end up getting your liquidity moved around, and that won't necessarily be a good thing for you. It'll definitely be a good thing for whoever decided to do it, because that's why they chose to do it.
I guess, the second point being is that private panels are not put into the public network graph, which means that it would do some of the compute costs of pathfinding, as well as increases the reliability of pathfinding, because a lot of private channels might not have a 100% well-balanced liquidity on either side. If that's the case, then because that information isn't knowable before you send a payment, it causes more payments to fail. I strongly encourage anyone who is using Lightning, but not trying to basically, up their routing game to open private channels.
[00:20:08] P: Interesting.
[00:20:10] TJ: Yeah. Absolutely agree.
[00:20:11] P: Interesting. You would recommend that basically, people that are not trying to be – That makes sense, actually. You're saying, people that are not trying to be routing nodes, they should have just only open private channels?
[00:20:21] KM: Yeah.
[00:20:22] P: Yeah, got it. Got it.
[00:20:23] SA: It also improves the pathfinding element that I mentioned before. What's happened right now, the default fee for LND for example, is 1 PPM. When you just start a new node, open a channel, it's 1 PPM. This leads to a lot of new users who have exhaust the channels, because it's so cheap, the liquidity is just come instantly.
The more major thing that happens there is that people who don't really care about routing and don't really care about fees, they pollute the network with 1 PPM channels. Very low-fee channels that are exhausted. This creates this effect that the whole network, it's like, really hard to find a path through the network with the pathfinding algorithm, because the pathfinding algorithm tries low-fee channels first, if that makes sense.
[00:21:20] P: Yeah. Got it.
[00:21:20] TJ: Yeah. If you're creating private channels, then you won't be able to route through those. Essentially, get SATS back when you're trying to actually pay with Lightning. Because if you're paying one direction, like an opposing flow and then be able to charge routing fees to reset that flow of liquidity by providing an opposing flow. Yeah. Private channels, you're totally right. Yeah, it would help you pay.
[00:21:47] KM: Someone just DM’d me a question from Twitter, asking if you would not be able to receive payments if you have private channels. That's incorrect. That's because in the invoicing spec, there is a method to embed the private channels in the invoice, such that the sender uses those as additions to the Lightning graph when they try to send the payment.
It's usually very useful for last stops. It's not tremendously well supported in all of the wallets. I actually tweeted about this not too long ago, basically, imploring every wallet dev out there to make sure that they support private channels, because of the benefits of A, protecting the liquidity of the end user, and B, not polluting the channel graph with a whole bunch of channels that are not routable.
[00:22:35] P: Yeah. Yeah. That is super important. It's really interesting, as I've got further and further down the rabbit hole, understanding the information that is stored locally by a node as it tries to basically send payments through the various routes. I'm really fascinated by the ranking system, or the penalties that are applied for failed payments and how that affects the ability to accept routes in the future, or to receive routes in the future. Alex, I see you're on the stage. Do you want to can you want to give us a brief introduction of who you are and all the cool shit that you've established? You can say no, of course.
[00:23:03] AB: Oh. Hi. I’m Alex Bosworth. I work at Lightning labs. We work on LND, and some liquidity products for routing, or receiving payments, like Lightning loop.
[00:23:13] P: You're selling yourself short, my friend. Alex is the creator of the boss score, which is, I think, is the first system for basically, trying to provide visibility into what makes a good routing node in Lightning Network, versus a bad one. It's super important, because by having these ranking systems that allow us to categorize our own nodes as effective, or ineffective routing nodes, it gives us more clarity around how to improve those metrics and those features, which is also something that Severin has put a lot of effort into. The terminal web debugger that that he’s created is a huge step in that direction. It gives us a lot more visibility into how to improve our nodes.
[00:23:53] AB: Yeah, it was designed from the opposite perspective. The perspective of the person who's trying to join the network, and they need the routing nodes. The idea is to decentralize the network. In order to decentralize the network, we need somebody who joins a network to have a bootstrap, like these nodes are worth your time to consider. Like how, when you join the Bitcoin, you reach out to these DNS peers, and the DNS seeds tell you about some reasonable Bitcoin node, so you can connect to – you can find. They're going to give you addresses of other Bitcoin nodes. After a while, you'll develop your own set of peers.
That was the idea is, we don't want the Lightning Network to just be everybody connects to the 10 big routing nodes. We want this to be a decentralized network, where you have a bunch of choices. If one node goes offline, it's fine. You have other peers. That's the idea is establishing that seed list.
[00:24:40] P: Yeah. Got it. Did you create the boss score as a way for you personally, initially to evaluate what were good nodes, or was the intention basically, to provide visibility for other people?
[00:24:49] AB: That project was done in the context of the Lighting Lab’s mobile app. The mobile app, we wanted to do it all, as far as make super easy to use accessible app for everybody to just join the Lightning Network. That was my high-level goal, which is okay, you downloaded this app. How do we make you have a good experience without running our own routing node?
[00:25:12] P: Got it. One thing and that somebody else said a minute ago, that struck me is in one of our previous conversations, Alex, you'd mentioned – I believe it was you. The excitement around Rust Lightning, which is another implementation that I think is, I'm actually unclear on what stage of development it's in. You were saying specifically, the ability to create a more nuanced, custom routing strategy was something that you were excited about.
Just a second ago, we were talking about the effect of connecting to 1ML, and how that might affect the way your own node, calculator routes. How long before we're able to implement those types of customized routing algorithms, so that we can as an individual basically say, okay, avoid these types of nodes in the future? Maybe that's a good thing.
[00:25:55] AB: Yeah. I think, the more tooling we have, the more the more libraries we have, the easier it is to try out these different ideas and execute them. On my node, I already have custom strategies. I have a list of nodes that I blacklist from all my routes. I have tooling to help me develop what that list looks. Right now, I pick all those nodes manually, but that could easily be dynamically done. Then, LND also has a new API in 0.13 that allows you to influence the mission control. The mission control is what does the pathfinding logic. That's an area of just experimentation.
[00:26:27] KM: It's also worth noting that LND and Rust Lightning will dump the entire channel graph to you, if you ask for it through one of the APIs, and then you can do your own pathfinding outside of the LND process. Rust Lightning is the library, not an actual node implementation. The point being that, if you dump the graph, you can write your own custom pathfinding logic, and then send directly to a route. LND has APIs for that, too.
[00:26:54] P: Oh, interesting. Alex, is that what Balance of Satoshis does? Is it already implementing its own customized routing node? Oh, I can't hear you. I don't know if you're speaking, Alex. Oh, man. Can anyone else? I don't know if it's my phone, or this is –
[00:27:08] KM: He's back on as a listener now.
[00:27:10] P: Okay. Yeah. One of the issues of Twitter Spaces is quite interesting, and it tends to boot people and do weird shit. Let me find Alex again and bring it back up. Go ahead. Somebody was going to say something.
[00:27:21] KM: I think it was Alex, but I think, just what we were talking about is the ability to do pathfinding in a more custom way, rather than leaving it up to the various implementations. I think, you were asking about what is the exciting thing about Rust Lightning.
One of the things that Russ Lightning offers is an entire Lightning implementation in library form. Right now, if you want to get at some of the more raw functionality within these node implementations, you have a few options. LND has a GRPC API. That GRPC API is much richer than what LN CLI gives you and what the config allows you to specify, but it necessarily requires you to write software that is in another process.
There's a similar dynamic in C-Lightning, where their plugin infrastructure, as opposed to having a GRPC API, the request responses happen over standard input, standard output, and so you can write your own plugins that can interact with C-Lightning. What's interesting about Rust Lightning is that it's all in the same process. You can get it down to a very low footprint. One of the consequences and Matt Corillo was very stringent about the way that Rust Lightning was set up, where it basically has no dependencies, which means that the actual binary footprint is actually fairly small.
I just heard of that project yesterday, that's actually working on compiling Rust Lightning to WASM and embedding an entire Lightning node straight in the browser. We'll see how that pans out in practice. I have numerous questions about how that's actually not going to work, but it's definitely one of the cooler aspects.
[00:28:54] R: Does this mean that the Docker container for Rust Lightning would be really compact?
[00:28:58] KM: I don't actually know, because for the Docker container, again, Rust Lightning is a library primarily. They do have a tutorial, where you can basically build your own Lightning node in five or six lines of code using that library. If you're talking about what it would take to build your own Lightning, using the Rust Lightning library and then Dockerizing that. In general, Rust binary sizes are pretty good, because there's no runtime. There isn't something like Go. I don't know how it would compare to something like C-Lightning.
[00:29:25] R: The reason I ask is because, someone is inevitably going to roll out a Lightning node package, which is containerized, like in Umbrel, if you install more than a couple apps and you have only 4 gigs of RAM, which most nodes do, they can start to crawl. I believe, that it can actually lead to some failures, such as Bitcoin D failing health checks. If three of them fail in a row, it can do an emergency shutdown. I believe, that's what happened to my node a couple of days ago. I'm very concerned about the docker container size of some of these apps and of Lightning redeeming itself.
[00:30:00] KM: Keep in mind that the container size is completely different than the in-memory occupancy. The container size doesn't actually have to fit all the way in memory. Because what Docker is doing is it's setting up a file system overlay. Obviously, any app that's going to have a huge Docker image footprint size is likely to have a high memory footprint, but that's purely based off of correlation of what I would describe as carelessness by the developers, and less so about some intrinsic link between the two.
[00:30:28] R: had a question, if Alex is able to talk. I think he's a speaker now. Hey, Alex. When can we have a truly grown node-based Lightning LND implementation?
[00:30:38] AB: If you update to 0.13.1, it should allow for [inaudible 00:30:41] Bitcoin D. It works by getting the blocks from the peers directly when they're needed.
[00:30:47] KM: It does seem to still be buggy though, Alex. I was talking to Wilmer about this last week. We deployed 0.13 to the embassy. 0.13.0. I don't know if this was fixed in 0.13.1 that came out today. When we deployed 0.13.0 and used the LND native print node support, it caused nodes to periodically go offline and then not be able to come back. Then, when we switched back to our block patching proxy that we had been using prior to 0.13, it seems to fix it. Now, I don't have any better evidence than that. I am working with Wilmer to try to nail it down, but we might want to be careful using LND’s prune node support, walking closely.
[00:31:26] AB: It is a brand-new feature, so your mileage may vary. The other thing I try to change is there's a catching system in it. It's not going to get every block from every peer. It's going to collect the blocks in the near timeframe that it might need. Then also, you can adjust your prune setting to say, “Oh, I want to prune everything, or I want to prune just the last two weeks, or the last month.” In some scenarios, it might be more reliable than others. Yeah, it's a new feature that hasn't been in the wild before. Yeah, there might be bugs.
[00:31:54] R: Thanks.
[SPONSOR MESSAGE]
[00:32:00] CK: All right, Bitcoiners. I want to tell you about our newest sponsor. This show is brought to you by ledn.io. I have been super, super impressed with the guys over at Ledn. I've actually known the co-founders, Adam and Mauricio for a very long time. I've had the pleasure to watch them build Ledn up from a tiny, tiny startup, to now a super impressive institutional grade, Bitcoin and crypto lender. Y'all, I'm so impressed with these guys. They are offering some of the best rates out there. I don't think anyone even comes close to touching them.
You can get 6.1% APY on your first two Bitcoin that you deposit into Ledn interest accounts, and you can get 8.5% on USDC deposits. I mean, I know all the competitors. They're not even close. If you're going to put your crypto and your Bitcoin into an interest account, Ledn is by far the best. On top of that, like I said, these guys are hardcore Bitcoiners, and they know the products and the services that Bitcoiners want and appreciate. They came up with B2X. It allows you to put your Bitcoin in and a leverage it up, and you can with one click of a mouse, get twice the exposure to Bitcoin.
If you're super bullish, Ledn has you covered with a super, super easy way to get leverage with B2X. Then on top of that, they know that Bitcoiners care about your reserves. They know that Bitcoiners don't like under-reserved and not full-reserved financial institutions. They are pushing the frontier in transparency in the digital asset lending space. They are the first digital asset lender to do a full proof of reserves and proof of attestation, through a Mariano LLC, a public accounting firm.
The Ledn guys, they know what Bitcoiners like. They are legit. I encourage you guys to check them out, do your own research and go to ledn.io. That is L-E-D-N.I-O and learn more.
[00:33:51] CK: Bitcoiners, I want to tell you about The Deep Dive. The Deep Dive is Bitcoin Magazine’s premium market intelligence newsletter. This is a no fluff, hard-hitting, incredible newsletter going deep into the market, helping you understand what's happening with derivatives, what's happening on-chain, what's happening in macro, what's happening with the narrative and what's happening with the tech.
My man, Dylan LeClair is an absolute savant. He is making his name known in the Bitcoin community, getting shoutouts left and right, getting on podcast left and right, and him and his team are bringing you everything that you need to know about Bitcoin. You don't even have to be on Bitcoin Twitter. You can ignore every other newsletter. This is the newsletter to rule them all. Go over to members.bitcoinmagazine.com. Sign up today. If you use promo code MACRO, you get a full month for free.
You have nothing to lose. What are you waiting for? Sign up, see the incredible work that Dylan and his team are putting out. If you don't like it, just unsubscribe. You don't pay a dime. If you do, it's going to be well worth the SATs and investment and understanding Bitcoin, and gaining the confidence to continue to invest in Bitcoin and making the right moves around Bitcoin. It's going to be well worth every single Satoshi. Again, can't recommend it enough. That is members.bitcoinmagazine.com, promo code MACRO. Do it today.
[EPISODE CONTINUED]
[00:35:22] P: Just to be clear. Rust Lightning is the idea that you would run Bitcoin core, for example, LND and then you'd use Rust Lighting as the library?
[00:35:30] KM: Rust Lightning would substitute for LND in that particular case. The primary difference, and this is – I'm taking a lot of this from their documentation. I had a couple of conversations with Matt Corallo about it, but the thing that they're going for is that the various node implementations make a lot of decisions with respect to how to store certain pieces of data and how the Lightning node fits into some broader architecture.
By busting up what makes up a Lightning node into its various sub systems and making those a bit – giving you the ability to control those from inside of another process, just gives you a lot tighter level control. By and large, it's not as well developed from a end-user perspective, as something like LND is, or even C-Lightning. As a developer, if you find that the other node implementations are not serving your needs, either doing due to being heavy, or awkward to deploy, or you need just lower level access to the actual individual protocol features, then Rust Lightning, I think, has an opportunity to serve your needs better in that way. It is a comparatively earlier –
[00:36:40] P: I'm so curious. How long before the people that are before all of you start really playing around with it, what needs to happen before you feel comfortable doing so and implementing it in your own tools?
[00:36:49] KM: Rust Lightning?
[00:36:50] P: Yeah.
[00:36:51] KM: I have to hate Rust less.
[00:36:55] P: That seems like a huge problem.
[00:36:57] KM: It is.
[00:36:58] P: Got it. Okay. Alex, how much have you built on top of balance – Do you use Balance of Satoshis as the intermediate layer between most of the stuff that you do on the Lightning Network?
[00:37:08] AB: I use that for my own nodes. I use that helping to manage the Lightning loop service and trying out different things. I have various test net nodes, test nodes. It's both what I use to manage nodes. Then also, to prototype different ideas, try different things out. It's built on top of my general Lightning library that I've been working with since I originally built yalls.org. It's built on that code base.
[00:37:32] P: Got it. How often do you LNCLI directly, versus the tools that you've built on top of it?
[00:37:38] AB: Generally, if LNCLI does what I want it to do, I'm not going to replace it with a new command. Although, Balance of Satoshis does have a new command, which we'll just call basically, LNCLI, so you can use it that way. Generally, I build the commands more for automating common tasks. Whereas, LNCLI is a great way to access API directly.
[00:37:59] P: Yep. I have one more question for you, then I want to open up a more open dialogue between everybody that's currently a speaker, so we can just riff and go into whatever we want. One of the things that was really interesting to me that that I guess, does the fact that C-Lightning, as I understand it, probing in the way that a terminal web uses a less not possible anymore. How does that affect the network and things like, terminal web and the tools that you're working on? Is that good or a bad thing in your mind?
[00:38:26] AB: I missed when it made probing impossible. What happened?
[00:38:29] P: Like Ace and Q right on terminal web. I like terminal.lightning.engineering. Ace and Q was the number one node forever, basically. Then very recently, my understanding is that the newest implementation of C-Lightning made it so that probes can no longer be used to basically, determine the channel balance.
[00:38:48] KM: Do you mean Éclair?
[00:38:50] P: I'm sorry. Is it Éclair? It’s not the C-Lightning?
[00:38:52] KM: Async is almost certainly using Éclair, instead of C-Lightning.
[00:38:54] P: Okay. I apologize. Not C-Lightning. Eclair.
[00:38:57] SA: I'm going to jump in for a moment here, because I believe a good chip connection problems. What Éclair did is basically, Éclair made the – I lift the payment sequence as a requirement. This as far as I know, disables key send, and also disables procs. What happened with async, or I don't know how to pronounce this node. It fell completely off the terminal score. That is because terminal score to some extent, uses probing to determine the health of a node.
[00:39:28] AB: I'm not working on terminal web. I can't get into exactly what happened there. I don't know. I don't think that you can necessarily make probing impossible, but you cause problems for it, for sure. Also, the terminal web, it's not probing your balances or anything. That's not part of how it works. I think, actually, async was deliberately removed from the original scoring list, because it was causing problems for probing. Maybe they don't want to be probed, so they were rejected. It was removed, because it wasn't working. I think, you can make problems for people who want to run probes, but you can't really categorically stop probing. You can just send a signal that you don't want to be probed.
[00:40:07] P: Oh, wow. Wait, so Severin, in the other chat, my understanding was that we'd come to the conclusion that Eclair no longer provided that information, but it sounds like, that's not the case.
[00:40:17] SA: I’m not sure if I understand your question correctly. Can you repeat that again?
[00:40:21] P: Yeah. I don't know if it was in the beta group, or in the advanced group, but I thought we had come to the conclusion that the newest version of Éclair, basically made it not made it not possible to reliably probe channels, as a result. It sounds like, Alex was saying, is that's actually not the case.
[00:40:39] SA: If you probe according to the probing research paper that came out two years ago, or so if you do it like this, then it's not possible anymore. They will return and a different error message. Yeah, it doesn't work. You can possibly get around with it, making one or two adjustments to the probing algorithm. Then it should work again. The standard doesn't work anymore with Éclair.
[00:41:09] P: Okay. Got it.
[00:41:10] AB: I don't really think that's the reason. Because they were actually upset that they weren't on the list, and they asked to be included. They asked for the exemption to be removed. I think, probably the reason that they're not on is unrelated to any probing changes.
[00:41:25] SA: Alex. What I saw on the Éclair GitHub is literally, they merged some code that makes the payment secret and the requirement. It's just coincidentally at the same time. Then async fell out of the terminal score, but it doesn't need to be, I don't know.
[00:41:44] AB: Yeah. I don't know either.
[00:41:45] TJ: One question that's coming up for me is Severin, in our conversations, we've talked about a really responsible use of probing. I'm curious, as probing grows and is more tools are built around it, how do you folks feel about, or how will the network respond in response to a whole bunch of probes happening across the network, or potentially irresponsible use of a probing that might not protect privacy, or that might be abusing individual nodes resources?
[00:42:17] P: Good question.
[00:42:19] TJ: Alex, I know we've talked before about how the network is resilient. How do you see nodes responding to excessive probing?
[00:42:26] AB: Yeah. I wouldn't necessarily even say probing. It's just what happens if you make a lot of requests. Like, what if you go to a webpage and you hit it a billion times and you get everybody to hit it a billion times? There's a level of abuse, even in regular things that people are expected to do. I think, that's a super important question for how does the protocol deal with this scenario? It conflicts with the goal of also making it, so that you don't know who's responsible for the traffic. Because it's not like, you can just put a rate limit on an IP.
You are getting the traffic from somewhere and you don't know where it's coming from. If you rate limit it, you're just rate limiting everybody. That actually makes the problem worse, because now, you've just increased the bang for the buck of doing an abuse. You basically shut off the node. I think, there are a lot of solutions for how this could be solved, but it does need to be prioritized. People need to be talking about this more, maybe than other things that they're working on, adding to the spec that are not thinking about how to harden the network.
[00:43:25] KM: Can you shed some light more on actually, how probes work? Is it done through the onion packet?
[00:43:31] AB: Probing is just a very generic way to describe doing a payment, that maybe doesn't succeed. The simple probe, if you use my tool for probing, all it's going to do, it's going to send the payment to the destination, but instead of the hash that the H and HTLC, the has, it's going to send random data. The nodes along the path, they won't know that's not the correct hash, so they'll still forward it. Then when it gets to the end, the end will reject it and say, “That didn't work for me.” That's one type of probe, and that's the most simple type of probing.
It can be useful when you're making a real payment. A lot of wallets actually do a probe before they pay, including the Lightning loop service. Before we actually do a swap, we do a probe just to test the route, to see is the route going to work for us? Once we know that the route is going to work for us, then we send along a real payment. It's not like, it's just information gathering for information gathering sake. It can be part of the regular payment flow.
[00:44:26] KM: Just to clarify here, so what happens is that the onion packet is sent with basically, a full route, or a candidate route to the destination. At the very end, the payment hash, the HTLC being offered to the final hop, the recipient is not associated with the payment hash that they've generated. They reject the HTLC and then the HTLCs get rejected all the way back to the source.
[00:44:49] AB: You can see, okay, my payment made it along this path. If I want to use that path again, there’s a high chance it's going to work. There's also the payment, like you were saying before that there's a payment non-secluded. When you generate a payment request in there, there's a random number that is encrypted in that payment that you make. Actually, if you use my probing tool, and you use it with it a payment request, it will still include that knot. Might even be compatible with the way that async is blocking and probing, because it signals that you have knowledge of the payment request. That's just way to probe.
Another way to probe is, you can pay past the point that you want to pay. That makes it harder to block it. How do you know if you're a routing node? How do you know that the payment is a probe, versus just paying one of your peers? That's how probing is a general concept of I'm just gathering information that was going to help me to do something.
[00:45:40] P: Okay. Got it. The statement that I had made that basically, Eclair is blocking, probing totally incorrect. I'm still a little bit unclear on exactly –
[00:45:47] AB: Well, they were always causing problem for probing. That's why they were not originally included in what I worked on. They weren't sending back the error, which was, I don't know about this payment. They always worked that way. Then, they did update their node and they also asked to be included in the scores. They were included for a while, but I don't know why they fell out.
[00:46:06] P: Okay. Got it. Just to be clear, my assertion earlier that running the newest version of Eclair has anything to do with this was incorrect. Is that right? It's a per node.
[00:46:15] AB: It might be correct. I really don't know.
[00:46:16] P: Okay. Got it. Got it. Got it. Because one of the things that's been interesting in PlebNet is that we've noticed that a ton of us have basically, jumped hundreds and hundreds of scores up on my terminal web, and I had thought that was because the newest version changed something, but –
[00:46:31] AB: It might change things. I just don't know, because I'm not working on the current version.
[00:46:34] P: Yeah. That makes sense. Severin, anything else that you would add to that?
[00:46:38] SA: No. It's actually a very good explanation of Alex on how probing works. There are ways around it. Even if they make the payments mandatory, like Éclair did. I believe, it has to do with the recent merge request I sent. Alex has sent you the merge request in the Lightning Labs [inaudible 00:46:58] group. You can have a look. They explicitly say, you can safely make it mandatory, which closes probing attack vectors in the merge request. It actually doesn't prevent probing, if you can get around it.
[00:47:11] KM: Yeah. The routing one hop pass, basically kills it.
[00:47:15] P: Just to be clear, the routing one hop pass is where you're sending a probe to one farther than the node you're actually interested in, or is that you're sending a payment one hop farther than the node you're actually interested in?
[00:47:25] KM: They're not materially different, but yeah, it's mostly – You're offering an HTLC that never resolves.
[00:47:31] P: P: Got it. Oh, that's so fascinating. Okay. One thing that you said, Alex, a second ago is that terminal web does not use probing to determine what constitutes a good peer?
[00:47:40] AB: It doesn't use balance probing. It's not like, figuring out everybody balances. As far as I know, that's not how it works at all.
[00:47:47] P: What do you think?
[00:47:47] SA: I'm not sure about this, because when you have a look at the chasing file that the terminal web score loads in the background, then there is one field that clearly states that you need to have minimal routable tokens of 1 million Satoshi. It clearly states minimal routable tokens with my debugging effort on a terminal score debugger on my website, lnrouter.app, there is a pattern that you must have. You must have 1 million routable tokens, but the pattern is not clear. There are some exceptions and I cannot 100% say that they do probing. They do something in this direction, but I don't know what they exactly do.
[00:48:32] AB: It does do probing. I'm not saying it doesn't do probing. I'm saying, it doesn't do the type of probing, where it narrows in on what your balance is from hour-to-hour, or day-to-day. As far as I know, it doesn't do anything like that. It just does more of an information gathering probing.
[00:48:46] SA: Yeah, absolutely. That's a big thing. Actually, a lot of people connect probing with private being privacy invading. I disagree there. If you don't really determine the balance of the channel. If you just chat, “Hey, would this payment will through,” which happens all the time in the network by just trying to find a path. I don't believe this is privacy invading, to be honest.
[00:49:14] TJ: What you could do for probing is just say, “Hey, can you route that 1 million Sat payment? Oh, no, you can't? How about a 500,000 Satoshi payment? Oh, you can. How about and just narrow in, how about a 750,000 SAT?” You can bring down that resolution on exactly what someone's balance is. Instead of doing the balance probing, you don't need that type of resolution. You're just curious, what can you route generally a large payment.
[00:49:43] AB: Yeah. Also, you can get the same information just by making regular payments on the network. Because every time you make a payment, you're routing through lots and lots of different nodes. Even if you're just making regular payments, you're already gathering that data, like who can forward for you?
[00:49:57] KM: Yeah. This is another reason that you might want to make your channels private, if you're not trying to be at router, is because you don't want someone to be able to zero in on the balance of your channels through a series of a binary search on the probing, whether or not you can route a payment.
[00:50:14] P: Yeah. Can't you create the same effect though by, I guess, you could still force it. Basically, by setting the max HTLC size? What if you had a 16 million SAT channel and then you just set the maximum HTLC to 100?
[00:50:25] AB: They can also stack HTLC.
[00:50:27] P: Yeah.
[00:50:28] KM: You can have up to 480 something HTLCs on a channel at once.
[00:50:34] P: Yep. Yep. Yep. Fair.
[00:50:36] TJ: One thing that we didn't talk about is private channels in parallel with public channels. I know, open arms and Alex have talked about this before. That's been fascinating, because what I was gathering was that you could actually use this private panel for routing in parallel with a public channel. That routing that liquidity in the private channel could actually be used for routing, if you have them set up in parallel.
[00:51:03] AB: Yeah. Another thing that I know, or I have heard of people doing, and I played around with a little bit myself is basically, having public channels and then private channels for rebalancing, which I think is it's related. Or are you saying something differently?
[00:51:14] TJ: Oh, I think earlier, we were saying that private channels couldn't be used for routing, but I was adding a little bit of nuance into it, because I think it's an exciting opportunity for people to maybe improve their privacy, or actually, yeah, make this probing question a little bit more difficult to get a handle on, and maybe clean up your offset a little bit.
[00:51:33] AB: Also, if you're a routing node, you might not want to advertise to nodes that you're connected to, or how much you're connected, because you're leaking information to your competitors about how much they should sign to a destination. I also think, the private channel mix could be interesting. Right now, a channel and a UT Excel or a one-to-one mapping. In the future, it could be that you could just have your channels be cold wallet UTXOs that are not actually used for the channel. They're just a marker, a placeholder that says, “I can route up to this amount.” Keep them on your cold wallet. Then, you can make private channels to be to manage how much actual hot wallet liquidity you want to have on your node. You can tear that down and raise it up.
[00:52:15] P: Wait, Alex. Can you elaborate on that? I don't quite understand. You're saying you could use UTXOs that you couldn't actually sign as you'd have it on the –
[00:52:23] AB: Right. From the perspective of the network, it doesn't know if the coin that you've referenced in your channel is actually being used for the channel at all. It's just a pointer. The cost of the pointer is just to sign a multisig without UTXO. It's conceivable that you could just have that UTXO actually be living on your cold wallet. You don't actually have those funds on your node. Even the funds could actually not even be your own funds. You could pay somebody else to create that pointer for you. Once you have that, then you would be able to manage your actual liquidity totally privately by making private channels that just follow along the same path. Whenever you receive a new HTLC, you just send it along the private channel, instead of the public channel that the sender referred to.
[00:53:04] P: Oh. Wait. You’re blowing my mind. Is that something that people are doing today?
[00:53:07] AB: We would also have no way to know. I don't know of an easy way to accomplish it, like using a current tool.
[00:53:13] KM: When you say that you people might use these things as pointers, the thing that's jumping out in my mind right now is that it's not clear why someone would want to do this. Because if UTXOs are small, for instance, that the idea that some people might want to do, I think, I've heard the practice called shadow routing, where they might open a 10 million SAT public channel and have a 100 million SAT private channel. At least, until amps are a little bit more widely used, that basically limits the amount that you can route over that link to 10 million at a given point, but you're hiding the private liquidity, or you're hiding the lion's share of the liquidity and the private channel.
However, that doesn't still change your hot wallet exposure as a result. It might not leak the information that you have that much available. If you have the reverse scenario, where the public channel appears, even though it might not belong to you, or something like that, appears much larger than a smaller private channel, if you look, that creates even more problems.
[00:54:11] AB: Yeah. This is a theoretical solution. I think, that it addresses one of the issues with having shadow routing channels, which has said, you limit yourself in what you can forward. You're turning away customers. If you have the public channel that's 10 million, but then you decide, “Oh, I want my shadow channel to have a 100 million,” the people who are sending, they don't know that you have a 100 million, so those 100 million sends are going to go to somebody else and you're going to lose that revenue.
Whereas, if you had one of these pointer UTXOs, you could set that to be a 100 million, but then only commit 10 million. Then if you decide, you want to go up, then you could add more shadow channels and your pointer will still remain valid.
[00:54:47] KM: You probably have to splice them, because well, link level can’t –
[00:54:51] AB: No. Because it really doesn't matter. LND will already switch your forward to the channel that has liquidity, even if you specify the different channel. The sender doesn't need to know about it, because LND will just automatically switch it over to the one that does exist.
[00:55:04] KM: Will it do it over parallel channels as well?
[00:55:07] AB: Yeah. That's the only time it will do it. If you have multiple channels with your peer and one of them is depleted and the other one isn't, but the center didn't know that, so they specified the one that was depleted, LND will automatically switch it over to the one that wasn't depleted.
[00:55:19] KM: Yeah. Sorry, what I meant is that if you advertise a 100 million, but you used to have 10 million and you said you wanted to up it, so you open up a second private channel with 20 million, you're still limited to 20 million in a single shot. Until link level amps have been – are those standardized?
[00:55:37] AB: No. The there's no link level amp implementation that I know of. Yeah, the problem is really with your peer isn't going to respect that you have this pointer, they're going to say, “I need to have the channel. I need to have those funds in the hot wallet.” It just gives you the flexibility to grow if you want it to grow.
[00:55:51] TJ: This is fascinating dialogue. I'm also curious if I can ask another question, P. Stop me.
[00:55:57] P: No. Please. The goal of this is basically, to have an interesting conversation. Anyone who's a speaker, but please feel free to dive in and ask questions.
[00:56:05] TJ: Yeah. Anoth
Read more: https://bitcoinmagazine.com/technical/lightning-network-devs-sovereign-computing
Text source: Bitcoin Magazine: Bitcoin News, Articles, Charts,
