Hello everyon! A few weeks ago, I was experimenting with commissions recommended by Chat GPT based on my manually collected data on various commissions. Chat GPT suggested using 1185 ppm for maximum profit. I tried it for a few days, but the results weren't that great. Then, I manually looked at which commissions in my table had previously given the best results. I just eyeballed it and thought that maybe 700 ppm would be optimal again, as it was a few months ago. I set it to 700 ppm, and for three days straight, earned commissions have been growing. Today was probably the best earnings day. I'm sharing this information with you. #LightningNetwork #Lightning #Bitcoin #fee

nostr:nevent1qqsv4lzhvmqljujj39c6zg7t5rpsvrc343lmx75q8eelz8a8mqswucqppemhxue69uhkummn9ekx7mp0qgsf5wdlsd7gdrtpakxvu6jv0g8tjm67t0xqs2kk4lw4f9ktv99z87crqsqqqqqphu0xqv

The last 24 hours of #LNBiG (fee rate 700ppm + 1 sat base fee):

Amount transactions: 3481

The sum of transfered BTC: 14.46587534

Percentile 0%: 1 sats

Percentile 25%: 10575 sats

Percentile 50%: 41896 sats

Percentile 75%: 223953 sats

Percentile 95%: 1361523 sats

Last 24 hours fee earning: 799958 sat (0.00799958 BTC)

#LightningNetwork

Sorry, your channel fell victim to the optimization I've been doing lately. Currently, I'm closing all channels that have been open for more than 30 days and haven't had at least three payments in the last 7 days. Probably that's why it was closed. I'm very sorry, but optimization requires sacrifices.

The last 24 hours of #LNBiG (2025-03-16):

Amount transactions: 25811

The sum of transfered BTC: 35.06102923

Percentile 0%: 1 sats

Percentile 25%: 592 sats

Percentile 50%: 10000 sats

Percentile 75%: 86062 sats

Percentile 95%: 564560 sats

Last 24 hours fee earning: 20886 sat (0.00020886 BTC)

#LightningNetwork #Stats

I just remembered that when closing a channel, I verify that the local balance or the remote balance isn't below a certain dust limit, roughly 600 satoshis. I think the situation you described falls under this exception. I'll review the code later, but I believe such channels aren't being closed on my end. Also, channels with active pending HTLCs don't get closed either.

In this thread, I'm thinking about network fees, whether it makes sense to balance them, what optimal fees to use, if it's worthwhile, just pondering a bit and so on. If anyone's interested, feel free to read. #LNBig #LightningNetwork #LN

nostr:nevent1qqs9awdrwhluqtpn3ghr649kjeyu0nly3njt4taw7fdhu4sxzf6x9xcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqs6xj49g

If I were to summarize, it seems to me that running nodes solely to earn from routing doesn't make much sense. I believe the future lies with nodes operated by merchants aiming to accept bitcoins, as well as nodes set up specifically to pay for various services. Both types of nodes will strive to maintain channels with other counterparties, making routing more of a side activity rather than a primary focus.

Fundamentally, I am an active user of the Bitcoin Lightning Network. I enjoy making payments wherever possible using this network. Therefore, my network of nodes essentially serves as hubs that I connect to with my wallets to pay for the goods or services I purchase.

Of course, I could shut down all these nodes, set up a small personal home server, open a few channels to the merchants I buy from, and that would likely work perfectly for me. However, on the other hand, I feel a significant responsibility for supporting the Lightning Network. As long as I'm able, I will maintain these nodes and support the network to the best of my ability because I really want as many users as possible to connect to this network and experience minimal issues while using it. Naturally, I always recommend my friends and acquaintances to connect and open channels with my nodes. I often don't tell them that these are my nodes, but I always recommend them because I know that if a wallet is connected to any of my network's nodes, there won't be any problems when making payments for goods or services, and transactions will occur with the lowest possible fees.

However, I'm concerned that my entire network relies on me as a single individual. I realize that if I were to fall ill or something were to happen to me, there is a significant risk that the funds in the channels could become stuck, and my family and relatives wouldn't be able to retrieve them from the channels. Moreover, at some point, the hosting service might simply shut down the server due to non-payment, leading to an unpleasant situation. Additionally, I don't want to trust the management of the nodes to hired employees because where there is money and assets, there will always be people looking for ways to take them for their own benefit.

As a result of all my thoughts and experiments, I've concluded that I can't find any optimal way to effectively earn money and maintain a high flow. It turns out that when you increase the commission, at some point the number of transactions drops significantly, but you earn more, and this happens not regularly but in bursts. It's very difficult to determine where you're right and where you're not. Therefore, I got fed up with all of this, abandoned it, and set fixed commissions on the channels. Initially, I set them to zero entirely, and the flow increased significantly. Now, if memory serves me right, my commission is 10 ppm, and about the same flow is occurring as when commissions were completely zero, but now I'm earning around $5-10 per day. It's possible to earn more, of course, but I just got tired of constantly changing the code and adjusting commissions.

Of course, when talking about earnings, it's important to keep in mind that I'm simply taking the numbers from the commissions. But you have to consider that every day some channels close randomly or at the request of the remote party, some channels get severed due to protocol mismatches with the remote side, or sometimes I open channels to nodes with which I don't have existing channels, and satoshis are also spent on that. So it seems like all earnings are being consumed.

But there's an interesting point. As you know, you can buy a channel on my website, and that server, LND, which manages it, has been showing me over the past few years that, in total, more than one Bitcoin has been accumulated from all the payments for opening channels. I keep track of these statistics; I don't have the data on hand right now, but it's roughly around one and a half Bitcoin earned already. This includes the amount I'm trying to cover for opening and future closing of channels, as well as the percentage I set in my source code based on the size of the channel.

So, in principle, you can probably earn money, perhaps by selling channel capacity rather than earning from commissions. Moreover, you have to consider that over the entire time my network has been running, which is about six and a half years, the difference between what I can get back when closing all channels and what I put into the system shows that I've lost approximately 3.3 Bitcoin. This includes several instances where my nodes were penalized and all funds were confiscated. There were also moments when there was a bug in the LND server, and breaches occurred. If memory serves, this amounts to about 0.8 Bitcoin in total. The rest consists of funds spent on commissions, opening, and subsequently closing cooperative or force-closed channels, which I was very actively opening in the beginning.

Simple example. Previously, I tried to balance channels using fees. I had an algorithm where if a large portion of the channel's funds was on my side, I set fees low until the balance shifted more toward the remote side. Once, I encountered a situation where I couldn’t send a payment to a seller through my nodes. I investigated and found that my wallet was receiving an error stating that the fee on one of my nodes didn’t match the fee the wallet obtained from the network graph. In other words, the node had a higher fee than what my wallet had in its data. I continued to investigate and discovered that the node had raised the fee several hours ago and reported it to the network via the Gossip protocol, but my wallet, which was always connected to the network at that time, did not receive this update and still had the old information.

I don’t remember all the exact details of that case now. I know that in the packet returned to the sender in case of an error, the new fees present on the node at that moment are included. But for some reason, my wallet didn’t set the new fee and didn’t resend through that node. I don’t recall why that happened. However, while studying that case, I concluded that balancing channels using fees has significant drawbacks because the fee percentage changes over time, causing many payments that could have gone through to fail. Subsequently, I at some point made the fees on channels fixed.

Later, after some time, I had the thought that balancing using fees probably has a logical flaw. Because when we have a large balance on our side, effectively locking up a large portion of our funds, logic suggests that this is an ideal scenario to earn fees. But channel balancing pushes us to use minimal fees in such cases. And channel balancing also pushes us to raise fees when liquidity in the channel is running low. From a logical standpoint, I think it should be the opposite. From a profitability standpoint, that is. A node should earn fees specifically when it has a balance in the channel and not earn them when it doesn’t.

Yes, the 95th percentile means that only 5% exceed the specified size, but day by day this figure fluctuates. Regarding fee optimization, I tried manually setting fees on all channels to approximately 800 ppm, and then progressively, over many days, lowering them and manually recording the number of successful payments, the total payment amounts, and so on in a spreadsheet. When you look at the results over a short period, it seems like you've found some optimal fee, but as more time passes, you realize that all these fluctuations have some other internal nature.

I tried to think about how optimization could be done, but it seems to me that this task is impossible because full optimization would require knowing the complete network graph with all node balances, which is fundamentally impossible. Moreover, this situation is constantly changing. Without knowing the balances of all nodes at a given moment, it's impossible to accurately predict which node will be optimal at any given time, which fee will be optimal, and so on.

Furthermore, payment paths and fees are set by the sender. The sender draws their information from the network graph, which always differs for each observer due to the slow propagation of gossip information.

Thank you, that's a good point. I hadn't taken that into account.

It has been five days since the mass closure of channels based on the principle that if there were no payments, neither outgoing nor incoming, in a channel within the last 14 days, I would close that channel.

I accomplished this by retrieving the ForwardingHistory list from the LND server, which returns a structure from which you can determine the channel to which a payment was sent and from which it was received. We take these fields and the timestamp available in the same returned structure and create our own virtual structure with lists of channels, the time of the last payment, and a counter of how many payments occurred over the past set number of days within that time window.

Experience has shown that despite closing approximately one-sixth of the channels by capacity, the number and amounts of daily transactions did not decrease—in fact, they may have even slightly increased. However, I believe this could simply be due to daily fluctuations. As a result, I am satisfied with the channel closures; the focus has shifted from quantity to quality.

nostr:nevent1qqsyazwagh5c2zmppz6g0gj5pjv3jmw24wtdg8euhsamqawq4s8rwsgpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqs6d8v9n

nostr:nevent1qqsgnysgsu6p4gzekmq9rnsa6ry9cvy9p7jmeg6yh2dexgengyyghhspz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqqqqsrws7ay

I just reviewed the logs from March 9th, the day I was closing channels.

All the problematic channels were on my node edge-1, and almost all of them are now closed, but one channel still remains open (c11795b2b5e4ab295a4055ce387345341547d3880208cf6499a9352672f86e90:0).

I started examining the logs at that time and encountered the following error (lnd): "unable to gracefully close channel while peer is offline (try force closing it instead): channel link not found"

I believe it was some sort of desynchronization during peer-to-peer communication.

The last 24 hours of #LNBiG (2025-03-14):

Amount transactions: 25390

The sum of transfered BTC: 25.54321901

Percentile 0%: 1 sats

Percentile 25%: 245 sats

Percentile 50%: 3175 sats

Percentile 75%: 52924 sats

Percentile 95%: 510422 sats

Last 24 hours fee earning: 17241 sat (0.00017241 #BTC)

#LightningNetwork #LN

The last 24 hours of #LNBiG #Stats:

Amount transactions: 31291

The sum of transfered BTC: 16.04263519

Percentile 0%: 1 sats

Percentile 25%: 56 sats

Percentile 50%: 848 sats

Percentile 75%: 12320 sats

Percentile 95%: 173687 sats

Last 24 hours fee earning: 9582 sat (0.00009582 BTC)

#LightningNetwork

I have a feeling that the node "c=" is experiencing some issues. The thing is, I've noticed that its capacity has decreased over the past few days. You can verify this yourself using the viewer at amboss.space. Another indirect sign of problems is that when I tried to cooperatively close channels with it a few minutes ago—channels that haven't been used for payments in 14 days—several channels were unable to be closed cooperatively, even though the node is online. This usually happens when a node has lost data about the channels. The node itself is online, but when a remote peer connects to it and requests, for example, to cooperatively close a channel that was with it, the node doesn't respond because it no longer has data about the channel. With this node, I have the feeling that this exact problem is occurring. It would be interesting to know from the owners of this node whether they are indeed experiencing any problems currently, whether they've had a failure or not. I think they have. #LightningNetwork

Thank you very much for your kind words!

On one hand, it might be possible not to close channels where there is maximum liquidity on the remote side, but in my case, it turns out that even if no payment has been made from the remote side to me in the last 14 days, that channel will also be closed. I think this is perfectly normal because if no payments have been made in such a channel with liquidity on the remote side for 14 days, it means that for some reason this channel still isn't working.

You could say that this is the largest channel closure on my end. In the past few months, a capacity of approximately 100 BTC has been closed.

nostr:nevent1qqsykhkn8rqqtazamdhkw0528tay7fhrgymz5cwgzpfdamvyqqs8fycpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyzdrn0ur0jrg6c0d3n8x5nr6p6uk7hjmesyz4440m42fdjmpfg3lkqcyqqqqqqgnyqv84

Hello everyone! I decided to try out a new optimization algorithm that came to my mind recently. It works as follows: channels that haven't been used to send payments in the last 14 days are considered suboptimal for maintaining liquidity, and I close such channels.

Also, to avoid closing channels that were opened less than 30 days ago, because I take on the commitment to keep a channel open for at least 30 days, I exclude those channels from this closing condition.

Previously, I thought a channel was well utilized when the amount sent and received exceeded the channel's capacity, meaning that payments at least once fully utilized the entire channel. But now I realized that's not entirely correct, because there could be channels that were used well and actively several months ago, but for example, no payments have been made in the last two weeks. Does it make sense to keep such channels? I think not.

Today's closing algorithm, it seems to me, won't lead to a decrease in the number of passing payments because it will close channels that haven't used a single payment through the #LNBiG network in the last two weeks.

What's most interesting is that there are actually a lot of such channels. It's approximately one sixth of the total capacity I'm using on my side in open channels at the moment.

Yes, and I almost forgot, I decided to execute the channel closures right now because the Bitcoin transaction fee is currently at its minimal level, and channels can be closed with a fee of 1 vbyte/sat

#LightningNetwork #Lightning #LN

Hi everyone! The node called Hub-1 has changed the server and IP address accordingly. A scheduled migration to another server, to different hardware, was carried out. Current information about IP addresses can be found in the Lightning Network Explorer amboss.space at this link:

https://amboss.space/node/034ea80f8b148c750463546bd999bf7321a0e6dfc60aaf84bd0400a2e8d376c0d5

#LNBiG #LightningNetwork