The last 24 hours of LNBϟG (2025-06-07):

Amount transactions: 8276

The sum of transfered BTC: 23.20924651

Percentile 0%: 1 sats

Percentile 25%: 20280 sats

Percentile 50%: 66762 sats

Percentile 75%: 126001 sats

Percentile 95%: 581009 sats

Last 24 hours fee earning: 513762 sat (0.00513762 BTC)

#LightningNetwork #LNBiG #Stats

The last 24 hours of LNBϟG (2025-06-06):

Amount transactions: 4520

The sum of transfered BTC: 8.52187651

Percentile 0%: 1 sats

Percentile 25%: 19242 sats

Percentile 50%: 50821 sats

Percentile 75%: 111610 sats

Percentile 95%: 497446 sats

Last 24 hours fee earning: 237553 sat (0.00237553 BTC)

#LightningNetwork #LNBiG #Stats

The last 24 hours of LNBϟG (2025-06-05):

Amount transactions: 6692

The sum of transfered BTC: 50.04548809

Percentile 0%: 2 sats

Percentile 25%: 30198 sats

Percentile 50%: 79817 sats

Percentile 75%: 246552 sats

Percentile 95%: 2550724 sats

Last 24 hours fee earning: 1521839 sat (0.01521839 BTC)

#LightningNetwork #LNBiG #Stats

The website lnbig.com will be moving to different equipment in the next few hours, so the site and channel sales will not be operational for some time. Thank you for understanding! #LNBiG #LightningNetwork

As far as I remember, this is the most successful day in terms of earnings from commissions. But such numbers and similar figures are not that common. Usually, in the last month or two, the volume (in bitcoins) of transactions was ten times less. The number of transactions on average has doubled, with an average of two and a half to three thousand transactions per day.

nostr:nevent1qqsfmzqgcg445uuw4c2x2ge8khttr7rqegvz24yx5jy4ucw8qrknangppemhxue69uhkummn9ekx7mp0qgsf5wdlsd7gdrtpakxvu6jv0g8tjm67t0xqs2kk4lw4f9ktv99z87crqsqqqqqp0ak8r4

#LightningNetwork

The last 24 hours of #LNBiG (2025-05-27):

Amount transactions: 5611

The sum of transfered BTC: 47.08249757

Percentile 0%: 1 sats

Percentile 25%: 18247 sats

Percentile 50%: 67440 sats

Percentile 75%: 248209 sats

Percentile 95%: 3421320 sats

Last 24 hours fee earning: 1730456 sat (0.01730456 BTC)

#LightningNetwork

And this is despite the fact that the total capacity in my network nodes is currently at a minimum, because in recent weeks and months I have been gradually closing channels that do not forward payments within 7-10 days, except for channels that have been open for less than 30 days (because when selling an incoming channel, I promise not to close the channel for at least 30 days).

nostr:nevent1qqsdwnv6vmu6d5zj3s79ejrrqy23n94zypl6a88czkh7c0t9kstyrlqpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqs7pjgvt

Today there's a huge earning from commissions. Not sure what it’s related to. Either someone was rebalancing, or there's a spike in payments and user activity, though that's unlikely. Very interesting. It’s the first time I'm seeing such numbers. And that's with commissions at 700 ppm.

#Lightning #LightningNetwork

nostr:nevent1qqsg6ruf9mw0a8leg72fxdzrd8l35p3wma7pf05ql06f2dkwqxaswqqpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqs8lfsna

The last 24 hours of LNBϟG:

Amount transactions: 3843

The sum of transfered BTC: 27.42699425

Percentile 0%: 2 sats

Percentile 25%: 19171 sats

Percentile 50%: 89772 sats

Percentile 75%: 394166 sats

Percentile 95%: 1604323 sats

Last 24 hours fee earning: 1301530 sat (0.0130153 BTC)

#LNBiG #LightningNetwork #Stats

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.

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.

Another interesting thought came to me.

If you run your personal node with the goal of using it to send payments from that node, perhaps it's a family server, and you decide to run it with public channels to also earn from routing, then here's another interesting rule for you.

Set a high outgoing fee for all the channels you have open to the public. Why do this? If you set a low fee—for example, by default, the LND server has very low fees like a Fee Rate of 1 ppm and a Base Fee of 1 millisatoshi—then your node could be used by other nodes in a way that’s not beneficial for you.

Quite quickly, a node might connect to you that has outgoing fees deliberately higher than yours. Such a node, connecting to you and opening a channel with you, can transfer its liquidity to you, squeezing out the liquidity that you have carefully distributed by opening channels to other nodes where you intended to pay for services. Liquidity from such channels will be redirected to these nodes, and your liquidity will be replaced by the liquidity of just one channel that is open with this malicious node. All the payments you want to make to vendors or services, with nodes you have diligently opened channels with, will be forced to go through only that single channel (because the liquidity will now be located only in that channel). You will have to use the fees set by that node further in other channels.

For what purpose might such a node do these bad things? There could be various reasons. For example, that node might just use your node to rebalance its channels. It uses its on-chain bitcoins to then put them in a channel with you, pump them through you to its other channels because your node had very low fees, and it would be financially profitable for it to thus rebalance its other channels through you.

Or perhaps it just opens this channel to you, and senders in the Lightning Network often choose this channel, as it promises cheaper routes.

Thus, we conclude. If you run your own node not with the goal of monetization, but to use your bitcoins for payment through the Lightning Network, always open outgoing channels and set them with deliberately high fees. Set fees that are even higher than the network average. In fact, you can use fees many times higher than the average. After all, if you pay from your node, then the first outgoing point, which is your node, incurs zero fees. So, no matter how much you increase the outgoing fee in your channels, it will not affect the fees of payments sent from your node. Therefore, in this scenario, you won’t make it worse for yourself. But by having deliberately high fees, you prevent such a scenario of liquidity pumping. And if someone still sends payments through you, you’ll at least earn decently, including on fees. However, of course, if you follow this advice, you're not likely to earn much from routing payments. But that’s not why we opened such a node. So everything will be fine here.

#LightningNetwork #tips #hints #LNBiG

nostr:nevent1qqsyz04aztt3mjx3f0nk9qpur6d6agclc379eq4y4y7n0yvu0swxtvcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqstqwjmz

I want to share some insights that came to my mind.

For example, if you have a channel with a certain node and you have an outgoing fee on your side, say, 200 ppm, and the remote node has a higher fee on you than your value, for example, 500 ppm, then it can be said with certainty that it's unprofitable for you to rebalance other channels through this one (to let liquidity flow into this channel).

So if you want to rebalance any of your other channels so that sats flow from such channels into this channel, it will never be profitable for you because you'll pay at least the same fee as that set on the remote side of this channel for rebalancing. In our example, this is 500 ppm. Therefore, when sats flow into this channel of yours and it's time to use them, and you send them to that side via forwarding payments, this channel will only bring you profit determined by the fee on your side, which in our example is 200 ppm. So you will always lose.

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.

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 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).

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.

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.

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.

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.

nostr:nevent1qqstkkt8qx9qxm4hy9u8flm0magjy0r57d05m3ex7xjg2mpdvpydmaspz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqsar2sp0

Hello everyone! I want to share my opinion on how much a node or multiple nodes in the #Bitcoin #LightningNetwork can earn for their owners, using the example of my own nodes. I will provide the figures as an annual percentage.

Currently, over approximately five days, the entire network of my nodes earns about 500,000 satoshis per day on average. This is an average parameter. 500,000 satoshis is 0.005 bitcoins.

The liquidity on my side across all nodes is roughly around 300 bitcoins. So, let's simply calculate the annual percentage. You can roughly calculate it like this: 0.005 bitcoin multiplied by 365 days divided by 300 bitcoins. Multiply by 100%, and it comes out to about 0.6% profit from fees, which are currently at 700 ppm + 1 sat base fee.

This formula does not take into account the costs for opening channels, which include on-chain fees for Bitcoin channel opening transactions, nor does it include various expenses related to channel closures, whether automatic or forced, cooperative or forced. We are just taking the net figure as if the same channels were open all year without any expenses. You should also consider the risks associated with 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.

Is this a profitable venture? You decide for yourselves. I just wanted to share some useful information with you.

Goodbye!

#Stats #LNBiG #profit #fees