Thanks for sharing. The thing is.... this is when you had your channels set to 700 ppm, right? I see you have been tweaking these fees recently.. I think you had a long period of zero fees, followed by fees around 1500, followed now by 700 -- given these changes, isn't it likely the network might "adjust" over time, and your 0.6% profit estimate might therefore vary widely? Or you are confident that, if you continued with 700 ppm, you would likely stay around 0.6% long-term? (FYI, we run The Megalith Node, had some channels in common for a while but none currently.)

Also, any insight on how you have ended up landing at 700ppm? Are you likely to keep it there or are still experimenting? Any why consistent fees for every channel, is it not better to set fees in such a way as channels might stay balanced and not become depleted in one direction?

Thanks for sharing! Super valuable insights.

Thank you for the transparency. This is greatly appreciated.

Thank you. Looks like something I wouldn't touch seen the risk/work/profit ratio

This is super interesting to play with, and also really valuable for lightning payments. 1sat and 700ppm seems huge tho, but this still returns only 0.6%... Hmm good question if it is. Somehow it raises a question in me, that how shall this play out on a node runner level, and on a market level. As a node runner you can run a node to host wallets, to help the network, or to make money. The latter is hard if you see this example. #nostr #ln #nodestr

3 types of ⚡ nodes Having run lightning nodes since early 2019, it's been great to watch the network grow, stumble, flourish, struggle and evolve .. my personal view is that there are three broad types of nodes now, and if you want to run a lightning node then be very clear about which sort before you start: PlebNodes: Sovereignty, privacy and p2p connectivity Run for sovereign access and control with two types of channels: 1. 2-4 channels with other *known* node runners - people who have got their shit together and keep their node up and/or let you know when/why it will be down; other plebs you know/trust; and .. 2. 1-2 channels into very well connected nodes that give you - and your plebpeers - much broader connectivity to the rest of the network RoutingNodes: Connectivity and economic return Larger nodes (measured by channels and channel capacity), that tie up significant capital (such as @LNBϟG - see below) and have a very broad reach across the network. They have resilient infrastructure, knowledgeable operations, are reliable, and economically keep their head above water at least at a nominal level LightningServiceProviders: Enablement, connectivity and return Like RoutingNodes, competently run and highly reliable with significant capital, and various service layers/offerings that enable applications and other services to utilise lightning reliably without having to deal with lots of the underlying technicalities. Like RoutingNodes, they need to make a return on capital and operational costs to remain viable. They're all important, and they each have quite different objectives, costs, risks and competency requirements. If you're curious about lightning I'd strongly recommend having a go! You'll learn loads, and using Zeus on your phone, connected to your own lightning node, whilst you're out and about at home, or travelling across the world is amazing and empowering! View quoted note →

what is the viable business model for the future?

I’ve always been really curious about this, so thanks for sharing the info. As things stand now, I see this as a process of building a reputation in preparation for the coming Bitcoin standard. When that day finally arrives, the ones who get chosen as real routing nodes won’t be those scrambling to hire people, set up nodes, and market themselves at the last minute — it’ll be those who have quietly and reliably run routing nodes for years without any issues. Someday, reputation might matter more than licenses.

the real bitcoin yield

If briefly, a year ago I was adjusting fees step-by-step from zero to about a thousand ppm and recorded in a spreadsheet how much the Lightning network was generating per day. After reaching a thousand ppm, I reduced the fees again step-by-step and continued recording. I ended up with a fairly large spreadsheet. The fees fluctuated daily, of course, but when I looked at which fees were generating the most satoshis per day, 700 ppm seemed to yield more on average than others. Not long ago, I tried feeding this spreadsheet to ChatGPT, and based on its analysis, it suggested using about 1185 ppm to maximize profit. I tried that, but it turned out not to be the best option. A few days ago, I decided to set it back to 700 ppm, as I did about a year ago, and again, this number proved very close to generating the most daily commission revenue. So I settled on that figure. I used to use a fee-balancing method, but then decided to abandon it. I'll look for where I might have written about it. Once I find it, I'll send you the link.

Exemple de calcul de rendement d'un noeud Lightning. #nostrfr #bitcoin

You also sell inbound channels, right?

Also small node operators have little chance of having incoming channels openened to them and must balance their outgoing channels by looping out sats which is not cheap either. Even if my node isn't profitable, when coupled with Lnbits, if offers great LN experience (via Zeus) to friends and family🐸

The majority of lightning node runners will have much less then 1 BTC. So it is more like "support the network". There need to be many nodes to avoid centralization. Setup and running a secure node is difficult enought and stops zhe majority of bitcoiners to have an own node. Let alone all the lightning managing stuff.

Just here to pay some respect for you supporting the #Bitcoin network 🙏 Since these: "annual node maintenance. These include hosting costs, creating backups, labor efforts, and the risks of node hacking, which could theoretically be hacked and have all funds stolen." Are absolutely not to be ignored ! #Respect

Size matters it seems. Joe Shmoe probably isn’t going to generate revenue worth the time and expense for a small channel. Thank you for your service🫡

@BTC Sessions can you provide your figures too?

I actually reworked my node with less but larger channels. Main goal is reliable larger payments with very little management. Because of this I don't route a lot, so my fees would be negligible.

Interesting that you abandoned the fee-based balancing method.

This!.

On the contrary, I think it makes sense for everyone to run their own small node to pay vendors for goods and services via Bitcoin Lightning through their own node, and also, if needed, to receive payments from others. The benefits are that a person controls their own funds, maintains privacy, and incidentally supports the Bitcoin Lightning network if it's a public node. Or, for businesses to run their own node to receive payments. These two scenarios seem most optimal for people who want to work with the Bitcoin Lightning Network. But running nodes solely to earn commissions from routing, I think probably makes no sense. Maybe a third option is to become an LSP provider and sell channels automatically, if such support is added to major wallets like Breez SDK, or Zeus, Wallet. Here you can earn from selling channels, and this will likely be more profitable than earning from monetization.

For small node operators, there's very little chance of getting an incoming channel, but it might not even be necessary. If you're running your small node to use as a family server for payments, your outgoing channels will quickly be partially emptied by sent payments, allowing you to receive incoming payments. You don't need to get incoming channels from anywhere for that. It's enough to just use the Bitcoin Lightning Network and pay for goods and services. In the end, even if you don't want to pay for any goods and services, you can just transfer some satoshis to a custodial wallet to have a backup option to pay if something happens to your node's internet channel. In fact, in the second paragraph, you indicate that you use it as a family node. Initially, when such a server is launched, if there are no incoming channels, payments won't go through. But by putting your bitcoins there, you can allow your family and yourself to make payments through the Lightning Network. And right after the first payments, you'll have incoming liquidity.

Yes, I have inbound channel sales, but only through a web form, not automatically like some wallet providers do, such as Zeus Wallet or Breez Wallet. I would be interested in trying this option automatically, but the lack of free time does not allow me to do this yet. In case anyone is interested, I keep track of how many inbound channels are registered through the web form per day. A few months ago, it was an average of one, two, or three channels per day, but in recent days, an average of four to five inbound channels are purchased per day. I don't track the sizes of the purchased channels, I only count the number of channels sold.

I may be wrong, but it seems to me that if you analyze several models, the least profitable one is running a node solely to earn on routing fees. I think the best option is for people to run nodes when they want to independently pay for goods and services through the Bitcoin Lightning Network while wanting to control their own funds and not rely on custodial wallets. And, of course, it also offers a privacy advantage. This is the first suitable method for running a node. The second method is when you open your own mini-store and want it to accept payments. In this case, it also makes sense to run your own node. Keep in mind that both the first and second options result in the node naturally becoming a routing node over time if it has public channels. So, I believe routing should be a secondary effect for nodes, and the motive should be different. There might be a profitable third option, though I haven't tried it yet. It's when you run your node to sell your liquidity by opening outbound channels for a fee (becoming an LSP provider, ideally in a way that allows the automatic sale of channels in some popular wallet. As far as I know, the developers of the Breez wallet offer a server that lets you act as an LSP provider. I haven’t tried this option because I simply don’t have the time).

Since you are online, I’m going to jump on this thread. You scared us a little when you closed a whole bunch of channels. Mine was one of the victims unfortunately.

Forgot to say, Hope all is good on your end of the channel.

I might be wrong, but it seems to me that channel balancing through fees has some significant downsides. Let me try to explain them. I personally witnessed a situation where I tried to make a payment from a mobile wallet and couldn't do it. The route went through my nodes. I started checking the logs and found that when the wallet sent the payment, it used fee parameters that were in the network graph several hours earlier. They were later changed to higher ones as liquidity decreased. At that time, I had an algorithm where if my channel's liquidity got depleted, the price would increase. For this reason, the payment couldn't go further. The sender's wallet used a lower fee because it saw that in the network graph, which didn't relay fresh data well due to the protocol's significant delay. Theoretically, when a payment doesn't go through due to fees, the intermediate node where it fails forms a response and sends new fees in that response. Upon receiving such a packet, the sender's wallet should, in theory, adjust the fees and resend it. Then, the payment would go through. But this doesn't always happen. It may be a bug in the system implementation or other reasons I can't fully understand. But at that time, I concluded that if I had fixed fees, that payment case would've succeeded, as the liquidity still allowed it. Then it occurred to me that balancing channels based on such a scheme—setting low fees when you have a lot of liquidity and high fees when it depletes—creates a sort of logical contradiction. When you could earn from fees with your bitcoins locked on your side, with this algorithm, you earn very little while your bitcoins are locked and available. When the channel depletes and you have fewer locked bitcoins, you need to increase the fee. This makes it unlikely that you'll earn more than when you had funds in the channel. It all seemed somewhat illogical. Therefore, I thought it would be better to just set a fixed fee. After all, when the channel depletes, adjusting fees only signals to future senders that we can't process a large payment through this channel. We financially discourage them from sending through us. But there are other ways to avoid losing profit (since higher fees often encourage senders not to use your channel at all). For example, if we lack funds in a channel and someone tries to send through it, our Lightning Network server would simply send a packet to the sender indicating that funds can't be sent through this channel temporarily.

I'm certainly sorry that some people saw this as a disappointment, but let's think a little. Imagine that using my tools and scripts, I get lists of redirected payments through channels and find that in some channels, for example, there hasn't been a single payment for 10 days (meaning no incoming or outgoing payments have passed in the channel for 10 days). I only process those channels that have been open for more than a month. I do this because in my web form, which sells channels, it's written that I will try to take on the obligation not to close a channel for at least one month. What conclusion can we draw if we are purely a routing node? I concluded that if my goal is to be a routing node, I need to maintain channels with nodes that are actively used and not maintain channels with nodes that don't use the channels. At least, a channel with no payments for 10 days likely has little value for the Lightning network and may indicate that for some reason, some senders in the network decided that redirecting payments through that node to me or from me to that node doesn't make sense, perhaps due to fees and such. I've closed many channels this way several times, and the statistics afterward showed no drop in redirected payments by amount or earnings. Everything remained as if I hadn't closed those channels. I always did this when Bitcoin network fees were at their absolute minimum. Usually, it was when the average fee was one, maximum two satoshis per virtual byte, and when the entire mempool was nearly cleared by miners. These were the moments when I did these things. Additionally, I always start by closing all these channels through cooperative closure. This means that when such a closure occurs, the two nodes agree on fees that are close at that moment. And it was usually one virtual satoshi per byte. So the cost of closing the channel for me or the remote node was at its minimum. If any node feels it needs to maintain the channel, they can open it again. And my algorithms won't close such a channel for at least a month after opening. If, after this period, payments are still poorly handled, I see nothing wrong with closing the channel again. Looking for more positives in this scenario, when we close channels that aren't often used, in my case, one payment every ten days, though sometimes I would close channels if there were fewer than three payments in ten days, it's also good for the Lightning Network as it cleans the network graph of channels rarely chosen by senders for payment transmission. There's also another benefit for myself, because when I mass-close unnecessary channels, it frees up a significant amount of liquidity that I then send to cold storage, as there's always a risk that the node or nodes could be hacked and the funds stolen. So it's always better to keep as few funds on nodes as necessary.

All good my friend. I meant to say we were a little worried for you. Glad it was all operational and normal. 💜💜

Interesting. The first think you are discussing ... "The sender's wallet used a lower fee because it saw that in the network graph, which didn't relay fresh data well due to the protocol's significant delay. " -- this is something I've seen a lot on the Lightning Network, but I've never seen it quantified. But anecdotally, there do seem to be nodes that are used to for payments which often "cache" old fee information from the network. My assumption is that many might be mobile clients with poor connectivity. It's actually for this reason that none of our nodes use "fast" automatic fee changes ... my experience is that you shouldn't change fees more than maybe once or twice a week for any given channel, because of this "caching" behavior. I've also seen attempted payments which are clearly using fee information that is several days out-of-date. Regarding this second issue, you write: "our Lightning Network server would simply send a packet to the sender indicating that funds can't be sent through this channel temporarily." Do you mean like with LND's "updatechanstatus" API?

UpdateChanStatus | Lightning Labs API Reference

UpdateChanStatus attempts to manually set the state of a channel

.... if so, wouldn't this prevent your depleting channel from "refilling" from the other side? Or maybe you are referring to a different strategy?

Regarding your last question, I meant that the Lightning Network protocol includes an onion packet type, when a payment fails due to insufficient balance. It needs to be pushed further. Then the intermediate node on the route sends back an onion to the sender containing an error code indicating that the channel temporarily cannot send the payment due to fee changes. It also specifies the new fees in the same onion. I haven't looked at it right now, I don't have the protocol on hand, but it's definitely there. And it's described somewhere in the Bolt specifications.

I got a bit confused. Also, answering your question, I mixed up a bit by indicating the wrong type of error. But generally, when a payment cannot be sent further because, for example, we don't have enough balance on our side to send it further, an onion is also sent, which indicates a temporary error code, and the onion is also sent back to the sender. From it, they can see which node along the way sent it, so they don't send the same-sized payment through the same channel again. Actually, I was talking in the context that instead of specifically regulating fees in channels that are drained, you can just rely on such packets to be sent to the sender if the payment cannot go through due to insufficient liquidity. And if there is still enough liquidity to make the payment, even if it's small, let such a payment go through at a fixed rate that was there at any balance of our channel. I hope I expressed myself more clearly.

You wrote.... "you can just rely on such packets to be sent to the sender if the payment cannot go through due to insufficient liquidity" .... Right -- "temporary_channel_failure" -- here

GitHub

bolts/04-onion-routing.md at 2b9c73b48c1920df8e7e867d110fab2d720a059b · lightning/bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications) - lightning/bolts

. The issue is that hitting failures like this has the effect of increasing payment latency for users, and also, if there are too many failures, the payment will time out entirely. Shouldn't we, for the sake of users, be trying to insulate payers from potential failures? And ....isn't a good way to do THAT is to simply signal to the network "hey, don't use this channel in this direction, I'm signaling this by putting my fees high"..... ?

Sorry that was the incorrect deeplink to the Bolts.. here is where I intended: " - if during forwarding to its receiving peer, an otherwise unspecified, transient error occurs in the outgoing channel (e.g. channel capacity reached, too many in-flight HTLCs, etc.): - return a `temporary_channel_failure` error."

GitHub

bolts/04-onion-routing.md at 2b9c73b48c1920df8e7e867d110fab2d720a059b · lightning/bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications) - lightning/bolts

I would think rather than fees, what you are both describing is the perfect use case for the max_HTLC setting? I know some noderunners don't use this setting for various reasons, but when it is used can signal to the network available liquidity (or lack of) while still minimizing or even preventing temportary_channel_failures.

Ok, so we understand it the same way. However, running an own lightning node is way to complicated for even avg. IT person. I hope this will increase. Have a own node with maybe 5 channels requires already 6M sats to be save. This is only enought for small payments in US and EU standards. Smaller channels could be risky if fees grows massive in future. Beeing to high to have small channels running.

please check your messaages

Thanks for sharing and thank you for helping the lightning network grow!

How is that possible? @LNBϟG is generating a 0,6% yield, and this seems more reasonable.