Suheb - Manage Your Lightning Node

Hi, you're listening to the Stephan Livera podcast focused on Bitcoin and Austrian economics. Today we've got an episode about managing your Lightning node, but first a word for the sponsors of the show. So firstly, check out Kraken, one of the world's biggest and longest standing Bitcoin exchanges. They've made a range of high quality hires and just recently Kraken We have acquired Circle Trade, one of the most recognized OTC desks, so this will provide new trading partners around the world, particularly in Asia, deeper liquidity and tighter spreads. So don't forget Kraken offer twenty four seven support, and they've got Kraken Pro mobile app delivering all the security and features you love about the Kraken exchange in a beautiful mobile first design. There's Kraken margin trading up to five times long and short, there is Kraken futures up to fifty times leverage to benefit from price swings or to hedge your price risk. Kraken is one of the most liquid exchanges, so you've got to set up with them. Go to kraken dot com to sign up. This episode is also brought to you by Unchained Capital. Unchained is a Bitcoin and technology financial services company that empowers customers with unprecedented financial freedom and control. Their products and services are built on the foundation of multi-signature and Unchained offer a two of three keys vault, which is a great option for those thinking how best to secure their Bitcoin for the long term. And if you have a Need to access liquidity without selling your Bitcoin? Unchained offer collateralized loans, so you can put up Bitcoin. All that Bitcoin is stored on-chain in dedicated multisig addresses, it's never re-hypothekated, you can share in the security of those keys and get USD liquidity. I'm really impressed with Unchained, they offer excellent services, they've released valuable content, they've got open source tools such as Hermit and Caravan. Check out my recent interviews with Parker and withdrew from the team. I think you'll enjoy partnering with With them, go and sign up at Unchained Dash Capital dot com. Have you backed up your Bitcoin seed? Look into Cipher Wheel by the company Cipher Safe. So your Bitcoin bip39 seed, when you set up your Trezor or Ledger or Coldcard, you wanna make sure you've got it in a way that's fireproof, waterproof, rustproof, petproof, and tamper evident. So the Cipher Wheel, it comes in a wheel shape, it masks the words of your seed, and you actually have to open a tamper evident seal. So make sure Make sure you've got your seed backed up, make sure you or your loved ones have access to your bitcoins if an accident occurs. So this product, it's available for pre-order, go to the website cyphersafe dot io, the link is in the show notes. Last but not least, GiveBitcoin dot io, I'm really excited about this company, it's the easiest and safest way to get your friends and family into Bitcoin. I'm sure you've seen it before, you've given Bitcoin to people and they lost it, they didn't know what they were receiving, they didn't get the

You can lock up that Bitcoin gift for, say, one to five years. Every month for the first year, GiveBitcoin is delivering a lesson from a world-class curriculum with input from many well-known Bitcoiners. I'm also an advisor with a small equity stake assisting with the curriculum. Just to clarify, it's not on-chain time-locking, it is locked up with Prime Trust, a qualified custodian. Don't forget, you can also get Bitcoin as a present, so you can put it on your wish list so other people can give you Bitcoin at GiveBitcoin.io. There's a lot of exciting things Thanks coming with GiveBitcoin, look out for them. I'll be having an interview with Corey on in the new year. So are you running a Lightning node, whether that is an LND one or a c-lightning node? This is the episode for you. So Suheb is the co-founder of RTL, Ride the Lightning, a popular Lightning dashboard. So I wanted to get Suheb on and talk about the app and how we made it and who it's made for, and just talk about some of his tips on how you can use the app to manage your Lightning node. So here is the interview. Suheb, welcome to the show.

Hey Stefan, thanks, thanks for having me.

So, Suheb, I know you have been doing a lot of cool work on RTL, and look, I think we'd love to just hear some of your story on how you got into all this.

Sure, great, and thanks for the opportunity to tell my story. So if you look at RTL, as an app, right? In reality, it's actually, you know, in its mission, it's actually pretty simple, right? just creating a UI layer on top of existing Lightning implementations. so in the essence, really a simple, job, right? But, if you look at the implementation, it turns out to be really complex because, we are trying to, create a power user, experience or give a power, power user experience, try to To, expose as much as we can in terms of the functionality, of Lightning implementations on the UI, right? So give a, create a user experience, UI focused, so that kind of makes it a little bit complicated in terms of all the functions that we have to handle, you know, try to think about what type of user experience to provide on specific functionality, so that makes it kind of complicated. So simple mission, complicated implementation

Yeah, and also, you participated in the Lightning Torch as well. Tell us about some of your early days experiences with Lightning Network.

Sure, yeah, that was really an exciting, you know, experiment and definitely, I'm, I'm actually number fifty or fifty-one on the Lightning Torch, so definitely that was exciting, right? so yeah, and I actually used RTL when I was, you know, participating in the Lightning Torch. so yeah, definitely it proves, first of all, that Lightning works. And being part of that, you know, carrying that torch and experiment and being part of the chain was really an exciting, you know, experience and a community building kind of, you know, lightning community building experience. So that was a great experience to be, to be having.

Yeah. And, and, maybe tell us a little bit about why you started RTL and when it started.

Yeah, sure. So, we've been developing RTL for more than a year now. so it started, with, my first ex- Experiment with Lightning kind of, so, you know, I set up my full node just after LND went on mainnet. so LND went on mainnet in, I think, March of 2018, and on April of 2018, I had my full node up and running on Raspberry Pi. I actually used, Statikus's, you know,

guide. Oh, Raspberry Pi, yeah. Yeah,

of course. Yeah. So I used his, his guide, to set up my node. so I had some experience of working on Raspberry Pis and some Linux experience as well. so it was pretty easy for me to follow that guide and set, set up the node. But once I set up the node, that's when I realized that, okay, you know, okay, I have this node up and running, now Open channels, I need to see, okay, how are my channels doing? Are my channels balanced? Am I routing anything? You know, at any point in time when I need to log in and view the status of my node, there are at least ten, ten, at least ten, if not ten, five different commands that I have to run to really get a good view of, you know, where my node is, right? What are the peers? What are the channels? There's so many things that you have to, you can do. And LND, you know,

Provided different commands that they have provided, so you, you kind of gives a lot of detailed view. So, so it became pretty apparent to me, you know, when I started operating the node that I need some sort of a dashboard, right? you know, the moment I log in, there are ten parameters that I need to see, and I need a good view of that, right? So that kind of became, you know, kind of a motivation to build this UI, and at that time there was no good UI available, and we wanted the UI to type of, user, it should be focused on, right? So, my view was that it should be a power user focused tool, for, especially, focused on lightning node operators, and what all they need to see, right? So, with that, kind of, user persona in mind, we started building, this tool called Ride the Lightning. so yeah, that, and we've been on this journey for more than a year now. We had our first release, in October of 2018, and it's, and it's been forty plus releases, forty releases. there are a couple of other things that we have done, on the side. so yeah, that is kind of the way we started.

And what's in a name? Why the name, Ride the Lightning? Yeah.

yeah, I'm not a Metallica fan to begin with, but, interestingly, when I was, so before I actually started building this app, I was, like reasonably active on, Bitcoin Twitter, and there is, one interesting, Twitter account called, goes by the handle, MediumSqueeze, and his, and that, handle's name is RideTheLightning. So I was very fascinated by, you know, that Twitter handle. and he's, he's kind of a, you can call him a maximalist, I think, in his views, right? So I like his views, I like his tweets, and I liked, you know, RideTheLightning at MediumSqueeze, I liked it a lot. So that was one good, you Account, I, I like that account. And, when we were like thinking about, you know, naming the app, it was, you know, kind of giving you a control over Lightning, right? It is giving you how to manage your Lightning node. So, we thought that, you know, Ride the Lightning is a good kind of, a name for this app, which is allowing you to control the power of Lightning, g-empowering you, so you know, you are able to ride the Lightning network with, with RTL. So that But, I hope Metallica fans aren't upset with me by using this, you know, for using this name.

No, that's great, that's awesome. And, I mean, for me personally, I use RTL, I have- Off the top of my head, I have at least three different s-instances of RTL running, right? I've got it on my MyNode, I've got it on my Notall, I have it on my BTC Pay, it's used in many different- Software, let's call it packages or hardware packages, because it's just such an easy tool to manage your lightning channels. So I think we can, we can maybe dive into more, more detail.

There's one interesting, sorry, I just, there's one interesting thing I wanted to actually tell you about, right lightning name. I was actually researching that a little bit. So right, the lightning, even the Metallica, didn't come up with this name originally. This name or the phrase was actually borrowed from a Stephen King novel. So it's an interesting, there you go,

okay, well, it's okay, when, when you're, when you're playing at a conference or something, you've gotta have like obviously Ride the Lightning as your intro song and everything, so.

Yeah.

Yeah. Yeah, that's great. So look, let's jump into some of the high level, what's it look like when you go into the tool? Typically, users who have, let's say, BTC Pay Server or one of these other products, like, say, Anodol, or I think even the new, Even the new Casa node will have BTC Pay server, and therefore with that, we'll also have RTL. So I think it's a very common package. So basically, my experience is, you know, you have the password, you log in, and then it presents you with the home dashboard. What are we seeing on this screen?

Yeah, so if you look at the dashboard originally, there are, there is, your Lightning balance, your on-chain balance. Lightning balance is essentially the amount of, funds that you have logged into your channels, and it actually g-is Coming side of it, you know, the liquidity on your side. So, that is one view, and then second is if you have any on-chain balance, you get one view of that. you get a view of how many channels are active, inactive or in pending status. you get a view of if the, node is routing, you know, forward, forwarding transactions, then, LND gives a different, has a beautiful API which gives you a view of daily fees collected, weekly fees collected, monthly fees That if the node is active and forwarding transactions, so how much fees you have been collecting. it also gives you a view of your channel balance comparison, you know, local versus remote, so that you can actually see, how balanced your channels are, and this is specifically very important for, routing node operators because ideally, they want to be routing in both sides, right? They want to be routing both incoming transactions, outgoing transactions, so they need the- Channels to be balanced, right? so that's a important parameter that you have on the top, and then a network view, you know, which is giving you a decentralized view of how your- Depending on the graph that your node has, what is the network view of that, node's graph, and this is one API again, LND has, so you get a view of that kind of give you a, you know, a bird's eye view of how your node is doing and how is the network, specifically, you know, a power user would want to know all this information

Yeah, that's awesome. And I think, for me, I've used RTL quite a lot just to get a quick view on what am I, what is my current state of my channels. And even if you need to fund your LND node, then it has its own little on-chain wallet, which is distinct from, say, like a Bitcoin wallet, like standard one, because LND has its own little on-chain wallet, and this is that A E Z'd one, right? Like the special seed. Yeah. And so then you can fund it that way. way, and then you can open the channel from your RTL node, or the other way is if you open channels from some other node in the direction of your own, you know, node so that you have the, like incoming capacity, obviously. So so I guess the main things that we're interested in as a Lightning node operator, and look, if you're, if you're listening to this today, you're probably a bit more of a power user, right? Because there are, well, let's see, on my RTL, there are, my node sees six thousand and seventy-eight other nodes out there, so that's Roughly how many there are today. let's talk a little bit about what you can, what you would use that for. So let's say you see the balance and you see the channels, what are some good tips there that you would, use? Like what would you manage with it?

Yeah, so, typically right, if you're a routing node operator, you'll, I mean, again, so there are different personas, right? So, depending on what persona you have. So, and, we kind of went back now, we'll actually get, maybe we'll get into the RTL or what's coming in RTL, you know, from a improvement perspective, so then I can talk more about the direction that we are taking, but, given the current persona,

What you would do is, one is discovery, you know, who do I need to connect with once you've started the node, right? so again, that is that functionality of discovery itself is not built into, RTL because it's not there in LND per se, although LND has an autopilot feature which allows you to, you know, discover and connect with the nodes automatically, but, what you can do is you can also go out on your own and figure out, okay, you know, there are certain lightning stores which are opening up or coming up with, you know, or going to provide option for, accepting lightning payments, so let me open a channel to them. So one is, you know, you find out, okay, these are good nodes to connect to on the network, you get their, node public key information, connect your node to them. So RTL kind of has this peer view, you can go to the peer view, put in the peer ID, the public key, connect to them. So the moment you connect with those, nodes, RTL Channel with that peer so that it is, you don't have to again go to the second page and, you know, discover where that peer went. So you can click on the control on the grid and same peer information is populated in the next page and you can fund whatever amount you want to provide on the channel and open the channel with that peer. So that is one thing, you know, connecting with the peers, opening a channel to them. Second thing, once you have your channels open, you can influence, the fees that you want to collect, when you're forwarding the payments, right? So, and there are multiple, factors that you can influence when you are adjusting the fees. you can a-adjust the base amount and you can adjust the percentage that you want to collect on the transaction amount. so there is a edit button on the channel, management page. you can adjust the fees per channel, you know, depending on whatever, whatever you think is a, is a good, you know Amount to charge for routing the fee, and you can also apply the same policy for all your channels at once, so you, you know, you need not manage per channel, tweaking, you can, you know, make sure that all of your channels are, you know, are kind of following the same policy also. So these are some of the controls available, to connect with the peers and manage, fee policies so that you connect, collect optimal fee on the, on the routing that you are.

That's great. So as an example, you might know about a submarine swap service, or you might know about a popular store, let's say the Blockstream store, and you might think, okay, people will want to pay in the direction of that store, and so it's advantageous for me, the Lightning node operator, to open a channel in the direction of that store or that service, and then theoretically that means people will want to route money through you, and so then As part of that, you will amend the fee on your channels to try to account for your cost as well, because obviously you're paying a chain fee, there is some risk associated, et cetera. And so then rather than leaving your channel fees as the default at whatever it is, like one milli-eh, mSat per, you know, million or whatever, whatever that number is, you can adjust that, and then hopefully over time, that, those numbers start to reflect real liquidity. Liquidity and real costs, as the network grows up, so to speak.

Yeah. So, typically, if a, you know, a big, operator is or, you know, an e-commerce player is going to open up, you know, abilities to accept Lightning payments, they would want liquidity providers to connect, with them, right? Tip, but what they would, encourage is, you know, people opening big channels, fat channels, right? to them so that they don't have to manage a Management also adds overhead, right? now, so what you, if you're a professional routing node operator, you can open, you know, commit big, funds or chunks to your, to those, e-commerce, operators. Then what you can do is, you can say that, okay, I've got channels with, these e-commerce operators. Now you can open small channels to my node, right? I will, so that you can route the payments through me. so for instance, if Amazon starts accepting Lightning Not allow you to open small amount of channels, to them, right? I, I, I would not, like, I would guess that they wouldn't allow this. so it will allow people to open big channels only. Now, so if you're a professional operator, you can open big channels, and then people can open small amount of channels, small, quantity channels rather, with you. So then you become the, the routing hub through which, you know, the traffic can flow. so and that's, that's kind of, so yeah, that is, that is the whole play that, you know, just opening channels on the one side isn't going to help. you need people coming into you which you can forward the payments to the e-commerce, operator.

Great, and also hopefully recently, okay, so recently Bitfinex came out with Lightning as well. So that's another example of a person who you might want to open a channel in that direction, and then other people same way would want to open a channel with you, and then they can transact with Bitfinex.

Yeah, so Bitfinex, for instance. For instance, had a capacity of, a, a minimum amount of four million sats, right? or Yalls, for instance, says that, you know, open a channel minimum five million sats, don't open less than that. now if, now you, you know, if you're an operator, routing node operator, you can open, but then you, you can keep your incoming capacity as, as, or limit as less so that, you know, people can open small amount, small quantity channels with you, then you become that The, hub for routing.

and let's talk about fees then. So can you tell us a little bit about the fee reports?

Yeah. So at this time, fee reporting is pretty basic, in RTL. So there are two ways to see the fee reporting. One is, on the dashboard itself, you see, there's a simple API available from LND which gives you a fee, a, a break-up of daily, monthly, weekly fee that is getting collected. there is another view, called forwarding history in RTL. where you can actually see your individual transactions, right? Whatever is going through your node, and for each transaction, what is the fee that you're collecting? So that is another view that you get. there's a third view called Routing Peers. Routing Peers actually is not giving you a fee view, but it is actually giving you, a summarized view, or a more of a, you know, analytical insight into, what is the traffic for incoming nodes and what is the traffic to outgoing nodes. So you can actually clearly see, you know, where is the traffic coming from and where am I routing it to, so which are my active, kind of network partners. and you can actually optimize Optimize your fee policy for those partners and the, the partners which are not active, you can make, the, the fee, you know, expensive maybe for them because they are using your liquidity, you know, lesser. so there are multiple ways to play with it, but, we are actually thinking of, giving even more insightful, you know, interfaces for, fee, specifically, giving you a more fine-grained view of, or a, you know, a timely trend of, you know, how your daily, monthly fee collection is actually changing over a period of time, so that you get more insights into how you're collecting fees, etcetera.

The routing page view also shows the events, so it's showing events And then the amount, and then obviously the alias of that person. So for example, if you're connected with the Zap node or the Breeze node or the Open node, node, and then it shows you, say, for example, one event and, you know, five hundred thousand sats, and it's showing, okay, okay, that's how much got routed through to that person, and then you can start playing off that and saying, okay, well There have been, you know, a lot of people wanna route in this direction, okay? Maybe it's a highly demanded route, maybe I can start charging or whatever, then it sort of starts, I guess that's where it starts to kick off in terms of Lightning Network. I mean, right now it's still early days, but it, it's,

you can open more channels, for instance, right? You can see that, you know, your capacity is getting depleted, or there's enough traffic for me to, like, sustain multiple channels for this Right. Yeah. And you can im- interpret that information and make it more useful.

And I think that is actually a point of difference between LND and C-Lightning right now, because my understanding is with LND you can do multiple channels with the same party, but I understand with C-Lightning you can only do one. Is that correct? That's right.

Yeah. With C-Lightning you can open only one channel.

Right. So I guess if you're a c-lightning user, you might need to close down the channel and reopen a fat one if you wanted to resize it.

Yes, that's right. That's one option.

Yeah. so let's talk about channel backups now. So, I see there's a channel backup window, and this is for the LND S C B, known as static channel backups. Can you tell us a little bit about that?

Yeah, sure. So, static channel backup, is actually a functionality which LND provided for taking backups of your channels. so that in case, your node gets corrupted and doesn't, boot up, there is a way for you to recover the funds, which have been, which have been locked in the channels, right? and, so, you know, when you start up your node, LND actually creates a default backup file also in its directory. so, but given that they have provided setup APIs, we also, provided a, an interface where you can actually do, Channel level backup if you want, or you can do a all channel backup. also whenever, you perform any channel activity, right? So for instance, if you open new channels or if you close down existing channels, Rill automatically takes up a backup also, right? so Rill is kind of automating that all channel backup, is always fresh whenever you are changing your channel states, right? now you can also specify the, the path where your, Backup file will be stored, in the RTL dot com file, so in the configuration file, you can store where you want to, you can configure where you want to store your backup file. so yeah, so backup, so RTL will continue to take the backups wherever you are, you are configured. the important thing is that you should, create redundancy of the backup file, you know, store that backup file somewhere else, where away from the node also, which RTL, there's no way at this point for RTL to manage. but at least make sure that you have a redundant copy of that file so that in case you have to recover, you have that backup file that you can use to recover, the balance, the balances which were locked in your channel, channels.

Right, yeah, I, for me, I periodically just pull a copy off of the device itself and keep it on another device, right? So for example, my main node one or my Mon, my Nodle one, I keep those, Elsewhere, just in case obviously something were to happen to it, then I've still got at least the static channel backup for them. And I understand there was also some people who unfortunately got caught out because they, they took a static channel backup While the channel was unconfirmed, right? Whereas I understand it's best to do it once the channel has confirmed, as in-- So I guess let me just walk that through just for listeners who aren't as familiar. So when you open the channel with somebody, it's still pending open until that on-chain transaction has confirmed on the Bitcoin blockchain, right? So every Bitcoin Lightning channel open and close is itself a valid Bitcoin transaction, and you need to wait for that to confirm and then do the channel backup. Yeah, so with, let's talk a little bit around channel management now. So I think we, we were touching on some of this before, but I think part of the, maybe what's a little bit harder right now is rebalancing your channels. So we have both what is known as a local balance and a remote balance. So again, just to make sure listeners can follow along, think of it like you've got an abacus and you have certain number of beads on either side of that abacus and I, I think generally speaking, most of the more professional ra-routing node operators are trying to keep it roughly fifty-fifty, not exactly, but just something in that range. If it becomes too unbalanced Let's say you've got ninety percent of the beads on your side and only ten percent on the other side, then that's not really great from a routing perspective. Now, there are, I guess, different approaches in terms of rebalancing. There is what's known as circular rebalancing, and there are certain scripts and so on, and then there's like the loop type services. Can you just outline some of your thoughts on that?

Yeah, so, you know, so first of all, why do we need to, balance, right? I think we should touch If your channels are, you know, lopsided or in one direction, there's only, the payments that can only come in that direction where you have the liquidity, right? It can't go in the other direction, right? so that is kind of a fundamental, you know- payment philosophy or payment, you know, algorithm basically, and go ahead and Lightning. Now, we need to, especially the routing node operators, ideally want to route in both the directions, you know? that's why impor-- it is important for them to balance. They don't want to lose because in each transaction that they're routing, they are making a little bit of fees, or revenue, so they want to maximize, traffic. Like it doesn't matter which direction the traffic is in, what is important is that traffic is flowing, right? So that is why it is important to have a balanced channel strategy so that you are always optimizing for maximum volume of traffic. Right? So, so that is the reason why we want to do it. yeah, there are multiple ways to do it. one is, self-routing where you can actually give routing hints, and, route the transaction in such a way that payment comes back to you in the other direction, by giving routing hints, right? that's one way to do it. but our-- in our deal, at this point, we are actually, we don't have any. Channel balancing, you know, strategy right now. we are actually looking to add loop in and loop out as, the solutions, for channel balancing. we have, we are not really looking to, add any scripts per se, which do self-routing, because one is, not all of those scripts are, you know, they don't always hundred percent balance the channels, right? So, it's very difficult to explain to the users how, you know, why the channels were not balancing if, if, Even if you have executed the script. So that's why we have decided to steer clear at this point, you know, unless we have any stable, well-tested, scripts out there, which can be included, via JavaScript, that's, that was another challenge. we have decided not to include those independent, routing scripts, for self-balancing. Loop in, loop out are good, you know, LND-supported tools, which can be used for channel balancing, and then depending on which side you want Both the solutions are available, for the users to, you know, make use of and balance their channels.

Yeah. So I'll just point out here for listeners who want more detail, check out my recent episode with Alex Bosworth from Lightning Labs. We talk a bit, little bit about Loop. but Suheb, from your point of view, can you just talk through what are some of the use case, the typical uses there for a Loop? In or for a loop out.

Sure, definitely. So, so loop out, let's, let me, let me start with loop out, right? so loop out is basically, you know, let's say you're a merchant, right? And, you are receiving a lot of volume of transactions, right? So, which means that the channels, might get lopsided on your direction. You'll get all your liquidity on your side. now, the, it's a well, it's a good thing that you're getting so much traffic

Creates is you cannot accept any more, transactions until you have the balance moved to the other side, right? So how do we solve that problem? And so loopout is, is one solution to that where what you can do is you can, so there will be two legs, to con- to, complete a loopout transaction, you will, make a lightning payment, which will shift the balance from the your incoming side to your outgoing side, and in lieu of that, payment that you did, you will get an On equivalent on-chain, balance, right? So, whatever, amount that you paid, there'll be a little bit of, you know, service, fees deducted or swap fee deducted, and you'll get the equivalent amount in on your on-chain balance. So you'll have your, challenge balanced and you'll get an equivalent on-chain balance. You'll be able to kind of like- withdraw the funds to your on-chain wallet and get your channel's balance. So to, to, again, to explain that, there are two steps. One is you pay a Lightning invoice and you get, on-chain, output to your wallet.

Awesome. And now the other way around, loop in?

Yeah. So loop in is basically, you know, you want to get, the balance on your side so that you can make the payment, right? but so without having to close the channel and open a new channel, right? So what you would need to do is you'll make, On-chain payment, and in lieu, you will get, an invoice paid so that you get the balance on whatever on-chain payment you made minus the service fee, and you get the invoice paid so that you get the balance on your side. So both loop in and loop out have, have two legs. have two legs. one is, the on-chain leg, and another is off-chain leg. so yeah, that's, that's in Loop, in Loopin, you're making a, on-chain payment and getting a, Lightning payment back.

And so let's talk a little bit about the fees associated for that. So typically there are different services, I know Alex Bosworth has SubmarineSwaps.org, and, you know, Lightning Labs will do that as a service as well. How do you think about using that in terms of the comparison of doing that versus closing down a channel and opening a new one?

Yeah, so, in terms of the cost, I think it is, definitely much more efficient to, do a loop transaction where you are paying a little bit of, you know, swap fee, but opening and close-- closing and opening, new channels will definitely be expensive than executing a loop transaction. so typically in the loop transaction, you have a on-chain fee component. And you have a routing fee component, and s-and overall, if you look at, the total cost, you know, compared to opening and closing a channel, you know, doing a loop transaction is, is, you know, Magnitude,

order of magnitude more, or, you know, less expensive. That's great. and in terms of other liquidity providers, so I know on the network there is LN Big, for example, and you can go to that LN Big website and you can actually request an incoming channel, or you can, another one is, Bitrefill's Thor channels, wh-where they do that as a service. So how do you think about using those? Is that something the routing node operator might think about, or perhaps this is more relevant for a-

Yeah, it's more of a, that's right, what you've rightly pointed out that that's a tool for merchants, right? If you're setting up, your shop to accept Lightning payments, how do you get inbound liquidity? That's your first problem, right? I need liquidity to, be able to accept payments or to be able to receive payments rather. So these players solve that problem, and I, I, I foresee a lot of players, you know, as Lightning gain, gains more prominence, Bitcoin overall gains more prominence, more adoption, I see more and more kind of players kind of getting into that space of, providing liquidity for, you know, merchants. loop in, loop out, Or rather, loop out provides a non-custodial way, to gain the same type of capacity, but, the professional node operators, like Bitrefill, for instance, offer more reliability, you know, in the channels, by providing services like Taproot. So, and that's actually, I, I believe that's a segment which will develop as Bitcoin and Lightning adoption increases overall. So, I think that is, it makes sense to have this type of service in the, in the market

So I think then there are two main profiles that you're building for and that are mostly relevant for people using Lightning today, and that's basically node operators, and then secondly, it's merchants. And so typically for those merchants, I guess- It'd be good to just talk through from, from their point of view. They may not necessarily be very Bitcoin and Lightning savvy. They may be more like somebody who just wants to set up and take Lightning payments, but maybe they want to self-manage, right? So maybe they buy a node or they, you know, they pay and get a VPS hosted BTC Pay server and they're taking payments with that. And I guess typically speaking, the typical things they wanna know is how much balance have they got? can they receive a payment? Have they got the liquidity for that? and then can they withdraw the money to a safer place? You know, take it on-chain or even to fiat if they, if they can? And typically, they, they might not wanna close the channels to get the money out, and I guess we've touched on some of those. But would you say that's basically a r-a good summary of the typical merchant? Pathways or things that they want to achieve.

Yes, so, you know, once we initially started out with having only a routing node op- operator persona in mind, but, with the BTC-P server integration, you know, the another persona which became, relevant for us was merchant node operator. I don't know if actually calling a merchant node operator really is, is the right term, but, you know, merchants operating lightning nodes rather to accept lightning payments. now, Their needs are different, right? So merchants are typically, we would, you wouldn't expect merchants to be, you know, very Lightning or Bitcoin savvy. so what information we need to provide for that persona so that, you know, when they log into RTL, they don't see things like, you know, routing fee or, you know, channel balance, channel, right? What does that mean? Right? So these kind of things, or even network graph, right? They aren't interested to look at network graph, right? What does that mean to them? So, so basically You have to create a different type of view, or at least a dashboard should have a different view of information for them, right? Which is relevant for them. And when I was kind of researching this, persona a little bit and, you know- shout out to Pavlo Nekh for giving us a lot of input on that from BTCPServe. So, and, you know, BTCPServe folks kind of deal with, merchant node operators, you know, day in, day out, so they have the best insights of what kind of, typical information they would want to see, and it kind of breaks down into very simple things. One is, how much, they can receive, you know, and how much they can send out. what is their Lightning balance? What is their How can they generate invoice? How can they make payments? It's as simple as that. So we have taken those elements and, in our new RTL design which we are currently working on, we are going to create, that merchant, focused persona, and the dashboard will have a different view than what you have currently in RTL. and it'll give them a view of, you know, what are their incoming channels, what are their outgoing channels, right? Keep them separate, give them a separate view, don't mix them so that, you know, it becomes confusing for them, and make it very clear to them how much they can receive, what can be the maximum amount they can receive, how much they can send out, what is the maximum amount they can send out. And then once we have created those views, we can add additional features like loop out, right? If they are lacking liquidity in certain Controls like LoopOut, so they can do channel-specific operations. so, you know, that gives a very, you know, much-in-focused, dashboard and control, which makes it, specifically easier for them to, you know, do their operations from Lightning.

Yeah, it still can be a little tricky in these early days because sometimes there might be a merchant who just starts up and maybe if they're more well known on Bitcoin Twitter, there'll be all these people yelling at them saying, "Yeah, take Lightning, take Lightning!" And it's sort of like, "Well, it's, it's not that simple yet." Like, "Yeah, it's easy for you to-- like, if you're an individual to send Lightning, yeah, that's easy, but like, when you're a merchant and you've got to set up to take the channels, wouldn't you say?

Yeah, definitely. I agree with that. There's a lot of education involved, and it becomes, a challenge, for mo-for onboarding perspective, right? You know, I open up a dashboard, all this information, I, I don't know, you know, what does all-what does all mean? Who do I go and talk to? And especially in a, decentralized application, you know, there's no owner, there's no marketing department, there's no education department, right? Everybody is in charge of

You know, it's how to put, put it mildly. but, basically, yeah, so that is the objective, that is the problem rather, and the objective is to kind of give them as simple a tool as possible, make it as, intuitive as possible, So that they can, you know, have their own control, and learn it easily. and that, that's another thing that we actually got as a feedback that, you know, people expect tools like RTL to be also educative, right? not just, operative. you know, when I'm clicking on, certain things, I sh- I want to understand what this, these actions mean. You know, what does channel balance mean? So- so that's what we are trying to kind of, those, those, that type of feedback we are trying to build into the new UX design, so that it becomes, descriptive, educative as well, and not just stay as a technical tool.

Yeah. And RTL, as we've mentioned through this conversation, has been packaged in with a lot of different software and hardware. what, what has been your view and experience with having RTL packaged in?

Yeah, that was a great experience, first of all, right? so when we started out, the collaboration, we initially started off with Raspberry Blits, that was the first collaboration, and, and most of these projects are Also kind of was, was starting at the same time as we were starting. So that was al-actually a good thing for us as well, right? They were also kind of hunting for UI solutions because when you're packaging a plug-and-play node, you know, you can give them all the hardware and everything together, but if they, you don't have a good UI solution, it kind of is kind of half baked only, right? it becomes very difficult to educate the user about, okay, you've got your node ready, now go to the S&L side and

Difficult, you know, from a user onboarding perspective. So if you have a good UI solution, which is even, even if it is basic, but it gives you an interface to start operating, that's a good, you know, leg up, for any node operator, so or other, you know, a node solution provider. So Raspberry Pi was the first, so and, and interesting thing is each, node solution provider we collaborated with, there were requirements, there were insights, there were requests which came, which helped us Let's make our TL a better solution, right? So when we started operating, or rather, you know, worked with the Raspberry Blits, you know, Rudzall came up with the requirement that you should provide an authentication mechanism. So we added the authentication mechanism, when we s-uh, started working with Nodal, you know, Kato Mine was always full of ideas, right? He is, really talented and full of ideas. So he, he said that, okay, why don't you have a solution to handle, multiple nodes Why? So we added that functionality. with BTC Pay Server, we had to dockerize the solution, right? So, you know, whatever, whatever integration, whatever collaboration we, we did, we ended up handling the requirements, making the RTL solution all the more richer. And of course, it's been a learning experience working with all these talented people in the space, it was really rewarding and interesting experience also.

That's great. And on the topic of collaboration, we have a-- There's a GitHub. For RTL, there is a Telegram chat, there's obviously the Twitter presence. What's been your experience there? What are the main ways that RTL contributors collaborate?

Yeah, so, typically we get a lot of, requests, on Twitter also, you know, in- initially when we didn't set up the, Telegram chat, we were, I was getting a lot of, DMs, you know, people struggling with, setups, et cetera, so I was kind of troubleshooting over Twitter's, DMs, or all, or rather, and then, GitHub, issues also, so a lot of, feedback came in, a lot of new requests came in, via GitHub also, which we were, consistently handling, you know, developing, improving RTL over a period of time. on Twitter, actually, we got a lot of boost from Pierre. Pierre is actually a good friend who helped us, you know, spread the word, and, and that was really helpful, for, us to get the distribution, you know, you know, year releases. We don't have a big presence, we have small presence on Twitter, but, Pierre kind of helped us give an initial boost so that we reached out to a larger audience to, you know, at least let them know about the solution. And, the, You know, make, do our part, in helping, Bitcoin and Lightning's adoption im-improve, so whatever we could do, whatever skillsets we can, we bring to the table, can we put that to a use and, you know, provide a solution which people can use. And my initial thought was that if we, develop a tool like RTL, the idea was to enable full node solution provider, and we, who can kind of set up their business and package this UI together and have a, you know, have a business ready to sell Right? that was the idea and, as more and more, solution providers integrated RTF, we got a lot of feedback from them. And, and I kind of work, you know, get a lot of feedback from Qetto Miner, get a lot of feedback from Broadrootsol, Pierre, you know, BTC Pay Server is very demanding. So, you know, all this feedback, kind of helps us make RTL a better tool.

Yeah. And RTL started mostly as an LND or LND only, solution, and I understand recently you're looking now at C-Lightning. Can you tell us a little bit with, your interaction on that?

Yeah, sure. So, yeah, so basically we wanted, so given that, initially, you know, Lightning users have now, some sort of, an experience pattern on how to typically operate a node. So now, you have a standardized kind of UI of, RTL, so we were thinking that can we extend the same functionality on C-Lightning also, you know, why just restrict to LND? the initial roadblock for us there, was that, C-Lightning didn't have a good REST API interface, right, so that, we could, you know, integrate a web application with C-Lightning. So that was a gap. I initially hunted for a solution, where, Somebody was working on a REST, REST interface for SeeLightning, I could reuse that, but I couldn't find a good, reliable solution for that. So what we, what happened was we ended up writing our own, REST interface, to SeeLightning, which was also a good learning experience for us. And then what we did was we kind of created a modularized version. So we created a separate REST interface and then integrate our deal on that interface. Now that interface can, in, in standalone, can be used by other apps also. So if you Or like in developer and you want to develop applications on top of c-lightning, you can use c-lightning rest as a solution to write web apps, so not just rdl, but any other web application can use that, that tool to, you know, write web apps on c-lightning. yeah, but that was the experience. Now, C Lightning, is, BTC-PayServer also provides an option of C Lightning, to its users. So, you know, once BTC-PayServer integrates, RTL C Lightning version, then, You know, they see Lightning operators also have that, this UI option available.

Yeah, that's really cool to see, and it's really, a lot of things are improving very rapidly. So I guess my next question then is more about Lightning more generally. So especially in the early days, it was very much seen as reckless. Yeah. Surely it's becoming less reckless over time, though still reckless right now. In your view, Suheb, when is Lightning no longer reckless?

that's a difficult question to answer, but, but what I would rather touch upon that, than is that, you know, what are the different developments that I'm looking forward to, right? And, you know, as those developments mature, we can say that Lightning is becoming less and, less and less reckless. and there are actually a lot ha- I think there's a lot of happening in this space. Typically, you can say that, and I read it somewhere, that you know, Lightning is maturing in dog years, right? so it is To ten months, you see so many improvements, so much, happening in the, on the protocol, so, it's im- it's evolving at a very rapid pace. So, one area that I'm definitely interested is in AMP, You know, or atomic multi-path payments, which, creates, packetized payment type, you know, protocol improvement, and you can divvy up your large transactions, divided into small, smaller payment packets, routed across different paths, and then, you know, bring it all together at the end. Adds, improves privacy of the protocol, improves, reliability on, on payments. that's definitely one, area where I'm very interested to see, you know, what's happening and how soon it can be brought then Sphinx sent, is another important area, right? where, where you don't-- so current experiences that you, if you want to accept, payment, you have to generate an invoice, somebody pays that invoice, and, you know, the kind of it's a little manual hand-off process. If, if with, with Sphinx sent, you can make, you know, push payments possible, that's, that's an amazing improvement and it'll improve the usability of, the protocol splicing is another, improvement which I'm very interested in, which will actually, help improve fungibility between off-chain and on-chain, you know, funds. it will improve your ab-- it'll add ability for you to balance your channels without having to close existing channels. That's, that'll be another option for you to balance channels basically. and, and so basically that's another area where, where I'm interested to see what's, what's going to happen. Trampoline payments, is, an improvement which is, I think, very critical for, Lightning scaling, you know, so if you look at, the way Lightning nodes currently operate, it's, each node is maintaining, its own graph, it is building its own graph and maintaining its own network graph. So whenever I need to route, payment, my node has a view of Looks at that network view, creates a network path, for the payment to go. Now, as the size of the network increases, the size of the graph that, each node needs to hold increases. and so Taproot and payment, is, is one solution on how you can scale, your routing capability without having to completely have a view of a complete network, right? So, so that's, that's another area of improvement which is very interesting to, to- Look forward to, and it's an important scaling solution also for Lightning. Watchtowers, is, is the, is another area where I'm very, keen to see, improvements, and it will help address, security risks and, you know, dishonest behavior, which is, very critical for people to kind of have trust in, you know, Lightning's, trustless solution. So these are some of the high level, Lightning, focus areas which I'm very keen on, and kind of watching it closely. once we have development on these areas, and once these areas considerably mature, then we can say that, you know, Lightning is maybe less reckless.

Very nice, yeah. I think there's, there's a lot coming there. So multi-part payment or, AMP as well. I've got an episode coming very soon, on that, so watch out for that one. with Sphinx send, I think the Lightning guys are calling that Keysend now as well. So that's that one. There was, there was a bit of chatter around that at the Lightning conference. and, and yeah, you mentioned a good one around splicing, and I think it's interesting as well to think about splicing versus looping out and I was saying splicing is sort of like a spot injection of more, you know, more capital, whereas looping is more like changing the balance inside that channel. And so that's an interesting thing to think about from a node operator's perspective, where you have to think about, okay, do I actually want to resize this whole channel to be bigger, or do I want to instead vary the amount that's already in there and just keep that the same? And I think maybe another thing that might be interesting as well is- Reliability scoring and, you know, BOSS scoring as well. So that's this idea of, you know, the longer you've had that channel, are you a more reliable channel partner? Do you have good uptime? And then that also may influence who people set up a channel with and where they try to route through, because there's a better chance of the payment being successful if you've got good uptime, whereas, let's say, some guy, he's like, his node is offline fifty percent of the time, you don't wanna send the payment through to him. Yeah.

So forward thinking a Right, routing node management, is going to be a lot more automated than, than manual, right? and, BOS scores, parameters like BOS scores help us move in that direction, right? So typically, if I'm operating a routing node, I'll not be op- or if I'm a professional routing node operator, I'll not be operating one node, right? I'll be operating multiple nodes, for instance, right? And you can't be looking at that node all the time to mon-mon-monitor all the parameters. What you need is some sort of a tracking mechanism, which, provide you signals for manual intervention. You don't need to watch things all the time, right? So your channels are getting out of balance. So create a signal or alert for a user to come and take an action or suggest even, you know, go in further and suggest some action that you can do splice in or you can do loop out, right? Whatever, right? So these are the options available, so then user can just take those, financial deci-make those financial decisions. Rather than, you know, technically, worrying about how do I do these operations, right? so that is the, kind of evolution that you will see in routing node operation. Routing node operation has to become much more automated than it is right now. We, we are just at this point picking up knowledge and information. All of this has to be encoded in al-algorithms, which will automate, you know-

So I guess maybe just summarize, your thinking in terms of what's coming next with RTL, what should people look out for next? I think particularly as you mentioned those two dashboard or those views that are coming for the merchant view and the routing node operator view.

Yeah, so, so basically at this point, we are focusing on, in completely enhanced or improving the UX. so initially what, what you have at RTL right now is a product of- product, of a product manager and a developer working together, without providing a, or giving in a lot of UX thought. Yeah, yeah, just, you know, we just put our thoughts together, created a diagram, and started coding this application. so we created our minimum viable product. Now we've got, reasonable traction with that product, and now we are kind of bringing in more of a UX discipline where we are now, you know, agonizing over each and every small feature, thinking whether the user needs to see this information. you know, whether these controls are, meaningful here. so then we are kind of revising the complete UI, so you'll see a completely different, user experience on RTL and hopefully a better one, with, you know, where we have actually now we are collaborating with, a person named Diogo Sergio, who is a UX expert and who wanted to collaborate with us, on the UX side of things, and he's a UX expert. so we are, that's one big area, so Hopefully that by the end of this year, a new release, where we have a different persona-based UX, where the dashboard will be different depending on the persona that the user has or the user chooses, and also the detail screen, the detail pages will have a different UX than what you have right now So that's one thing that we are working on. Second thing after that will come, is the loop in and loop out integration, where LNB is also very keen on, having a UI solution in place. So, that is something that, that, that will be coming after the UX improvement. after that, we want to actually focus on, node monitoring, right? Like what I said about, automation, is something that, is, I'm very keen on, that, you know, whole routing node operation has to become, more and more automated. So what are the tools available? What type of, you know, functionality we can provide? What type of, alerting mechanism we can provide so that we can kind of move in that direction where the user needs to do less manual work and can get more alerts so

Yeah. Oh, one other thing just came to my mind now, mobile app, have you thought about that or is it more just like have the web user, interface work on a mobile device?

so at this point, not an app per se, but yes, all the, RTL interfaces will be responsive, so that, if you're opening the same app in the u- in a, in a mobile interface, it will adjust to the resolution and give you a more optimized, user experience. Not, the same web experience basically.

Great, that's awesome. look, I think that's, they're the main points I had to ask from you. Maybe just tell the listeners where they can keep up and follow you online.

Sure. so there are two ways. One is you can, find me on Twitter. my handle is at suheb underscore underscore two underscores. and then if you want to follow just the RTL, developments, you can follow us at, at rtl underscore app. So that's another handle which you can Can use to find out any developments related to RTL. Happy to answer any questions.

That's awesome. And look, yeah, I've really enjoyed chatting with you, and, yeah, it's really exciting to see all the stuff that you're doing. I really, I, I like using RTL myself, so, it's a great pleasure to chat with you. Thanks for joining me.

Sure, thanks a lot. Thanks for this opportunity. Thank you.

So there you go some tips on how to manage your lightning node with RTL. So make sure you check that out and make sure you share this episode with any of your friends who are interested to run their own lightning node. You can find the show notes and the transcript on my website stephanlivera dot com. This is episode one hundred and thirty five. That's it from me. Thanks for listening and I'll see you in the citadels.