LNBϟG

Official LNBϟG account in Nostr ;-) I like zaptoshis! :)
E-mail: hello@lnbig.com
SimpleX: https://simplex.chat/contact#/?v=2-6&smp=smp%3A%2F%2Fhejn2gVIqNU6xjtGM3OwQeuk8ZEbDXVJXAlnSBJBWUA%3D%40smp16.simplex.im%2FNnGdg9PBPg0uaTinG_11zZ7j5jX2QwXL%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEA0F3-LRe490bk_FV00E6Y2rySPuW_jE0R6FgyPK1dDUo%253D%26srv%3Dp3ktngodzi6qrf7w64mmde3syuzrv57y55hxabqcq3l5p6oi7yzze6qd.onion

Public Key

npub1ngumlqmus6xkrmvvee4yc7swh9h4uk7vpq4ddt7a2jtvkc22y0asrse3pv

NIP-05 Address

boss@lnbig.com

Profile Code

nprofile1qqsf5wdlsd7gdrtpakxvu6jv0g8tjm67t0xqs2kk4lw4f9ktv99z87cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsysy4pk

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1ngumlqmus6xkrmvvee4yc7swh9h4uk7vpq4ddt7a2jtvkc22y0asrse3pv

Show more details

Last Notes

2025-12-10 18:03:36 UTC

Today is a new record in terms of volumes transferred.
#nevent1q…g3uq

2025-12-10 18:02:59 UTC

The last 24 hours of #LNBIG (2025-12-10):
Amount transactions: 71425
The sum of transfered BTC: 426.12361997
Percentile 0%: 1 sats
Percentile 25%: 44131 sats
Percentile 50%: 123295 sats
Percentile 75%: 340702 sats
Percentile 95%: 2000175 sats
Last 24 hours fee earning: 8056202 sat (0.08056202 BTC)
#LightningNetwork #Stats

2025-11-09 20:24:28 UTC

The last 24 hours of LNBϟG (2024-11-09):
Amount transactions: 28872
The sum of transfered BTC: 244.09300409
Percentile 0%: 1 sats
Percentile 25%: 40002 sats
Percentile 50%: 127485 sats
Percentile 75%: 331288 sats
Percentile 95%: 2560102 sats
Last 24 hours fee earning: 8900349 sat (0.08900349 BTC)
#LNBiG #LightningNetwork #Stats

2025-11-09 06:39:06 UTC

The last 24 hours of LNBϟG (2025-11-09):
Amount transactions: 14889
The sum of transfered BTC: 157.36706758
Percentile 0%: 1 sats
Percentile 25%: 31670 sats
Percentile 50%: 119119 sats
Percentile 75%: 461294 sats
Percentile 95%: 9501678 sats
Last 24 hours fee earning: 7211900 sat (0.072119 BTC)
#LNBiG #LightningNetwork #Lightning #Stats

2025-11-05 07:56:10 UTC

2025-11-05, #LNBiG #Stats
The last 24 hours of LNBϟG:
Amount transactions: 17724
The sum of transfered BTC: 144.77642968
Percentile 0%: 1 sats
Percentile 25%: 20009 sats
Percentile 50%: 97507 sats
Percentile 75%: 320121 sats
Percentile 95%: 2233562 sats
Last 24 hours fee earning: 6590212 sat (0.06590212 BTC)
#LightningNetwork

2025-11-02 14:13:43 UTC

Check out this thread of my thoughts on where the main liquidity flows in the Bitcoin Lightning Network and how big earnings come from transaction fees.
#nevent1q…252x

2025-11-02 14:09:45 UTC

- reply

Interestingly, if you look at the fees charged by Binance on all other nodes, you’ll see that their outgoing fees are almost zero. With such low fees, it still turns out that all the liquidity flows from me, for example, to them at Binance, and hardly comes back. And if it does, it quickly flows right back to Binance. However, it seems that Binance is becoming the perfect routing node for third-party nodes. It’s advantageous to connect to Binance in order to send payments elsewhere, since the outgoing fees from the Binance node to all channels are zero. (But it should be noted that due to whitelists, Binance has a very limited number of nodes that can open a channel to them.) Thus, it seems that Binance is signaling to all other nodes that they want to offload liquidity in their channels and are willing to send payments further for no fee. Yet, this still isn’t happening. Apparently, all the channels on Binance’s side are filled with liquidity that’s accumulating with them.
In other words, to sum it up, Binance is a huge vacuum cleaner for Lightning Network liquidity among all the Lightning nodes I know of.

2025-11-02 14:02:01 UTC

- reply

There's an interesting situation here. In this scenario, the more liquidity you have, the greater the earnings because you have to take on-chain #Bitcoin and use it to open new channels on Binance. After a short time, a flow of liquidity from other nodes heads into these channels, as I mentioned earlier; it's either private channels or the Boltz service leading the way. This way, liquidity gets pushed into the #Binance and #OKX exchanges, while lower-quality liquidity, like that from private channels, flows in.
Of course, you can write scripts that will close such private channels because it's unlikely the flow will go the other way. The freed-up liquidity can then be used on-chain again to open channels on these two exchanges, again and again. However, if you don't close the channels that injected liquidity to send on to these two exchanges, you'll need to add more on-chain Bitcoin to your nodes and open channels again.
You also need to keep in mind that Binance has #whitelist nodes by default that are allowed to open channels with them. At one point, they added a couple of my nodes, so I can open a channel with them. However, most nodes don’t have the ability to open a channel on Binance, so they have to connect to intermediaries like me and open channels with me to send payments to Binance.
Everything mentioned above is indeed the main reason for the increased volume over the past day and such high earnings on fees.
#LightningNetwork #LN #fees

2025-11-02 13:55:44 UTC

- reply

Claude Code, a console tool, is extremely helpful when it comes to writing processing statistics based on certain criteria, and now all the tedious work can be handed over to it, and it writes everything very well. It might not get it right on the first try, but after a few iterations, it produces very good code. For example, with its help, I wrote and refined the code for setting automatic commissions, which is currently working for me. I also created tools for displaying statistics on the console to track incoming and outgoing flows in order to identify trends. This is primarily needed for myself to understand how to improve commission earnings.

2025-11-02 13:52:10 UTC

- reply

#nevent1q…r6hn

2025-11-02 13:49:49 UTC

- reply

So, it turns out that the main huge flow of funds is going to the exchanges Binance and OKX, and it could also be going to the Kraken exchange, but they have closed the option for opening incoming channels.
Indirectly generating income is the top node Boltz, which is the service for exchanging Bitcoin on-chain to Lightning and Lightning to on-chain.
Also, my share of local balance for private channels has grown significantly. So I can assume the following scenarios for why this is happening.
Someone is opening private channels to me and paying on Binance. This is probably done because Binance by default has whitelists for nodes that can open incoming channels to them, while other nodes in the network cannot open those channels on Binance. They only have the option to work through intermediary nodes, including mine. But that's not the main flow; otherwise, I would see private nodes in the top indirectly generating income. Well, Boltz is at the top.
So it seems the main scenario is that people are funding their accounts on Binance through the Bitcoin Lightning Network, using either wallets integrated with Boltz, where you can pay #Lightning invoices through Bitcoin on-chain, or directly using the #Boltz service since they have a website. They pay Lightning invoices issued by the #Binance exchange, settling with on-chain Bitcoin. Why this is happening, you can guess for yourself. Maybe it's done for privacy because on-chain Bitcoin is easily analyzed, and the Binance exchange can ask various inconvenient questions for every incoming Bitcoin on-chain transaction, while Bitcoin Lightning Network transactions have no connection to Bitcoin on-chain transactions since all payments come only from the nearest channels. And where they came from, there's no information due to the privacy of #Bitcoin #LightningNetwork
#LNBiG #Stats #OKX #privacy #LN

2025-11-02 13:41:58 UTC

- reply

Actually, I understand a bit more about what's happening and why it's happening. Just yesterday, I opened new channels on the Binance and OKX exchanges because all channels on these two nodes get drained really quickly. I even created new console statistics commands using AI tools that allow me to track which nodes are generating income, meaning the nodes that are receiving the financial flow. It's from outgoing payments that I earn through commissions, and I can track the indirect nodes that generate income, meaning where the financial flow is coming from. Incoming payments don't bring direct income, but they do generate income on the exit where they are redirected. So it's also important to consider indirectly incoming nodes that generate income.

2025-11-02 13:39:07 UTC

The last 24 hours of LNBϟG (2025-11-02):
Amount transactions: 19259
The sum of transfered BTC: 118.86707353
Percentile 0%: 1 sats
Percentile 25%: 11781 sats
Percentile 50%: 78254 sats
Percentile 75%: 231757 sats
Percentile 95%: 1281921 sats
Last 24 hours fee earning: 2551270 sat (0.0255127 BTC)
#LNBiG #Stats #LightningNetwork #WtF

2025-11-02 13:38:12 UTC

- reply

It turns out this wasn't the best day. Today I'm publishing new statistics for the current day.

2025-10-31 14:24:41 UTC

The last 24 hours of #LNBiG (2025-10-31):
Amount transactions: 18919
The sum of transfered BTC: 84.75279582
Percentile 0%: 1 sats
Percentile 25%: 5005 sats
Percentile 50%: 40000 sats
Percentile 75%: 160000 sats
Percentile 95%: 1280002 sats
Last 24 hours fee earning: 2161765 sat (0.02161765 BTC)
#LightningNetwork #LN #Stats

2025-08-27 15:16:14 UTC

These figures are record-breaking; I don’t recall ever having such a payment volume before. At the moment I have 500 ppm + 1 sat base fee...
#nevent1q…lspa
#LNBiG #LightningNetwork #Stats

2025-08-27 15:13:33 UTC

The last 24 hours of LNBϟG (2025-08-27):
Amount transactions: 2921
The sum of transfered BTC: 63.89620476
Percentile 0%: 1 sats
Percentile 25%: 9134 sats
Percentile 50%: 30114 sats
Percentile 75%: 160083 sats
Percentile 95%: 15206188 sats
Last 24 hours fee earning: 1212933 sat (0.01212933 BTC)
#LNBiG #Stats #LightningNetwork

2025-08-25 16:15:57 UTC

The last 24 hours of LNBϟG:
Amount transactions: 3187
The sum of transfered BTC: 48.07892988
Percentile 0%: 2 sats
Percentile 25%: 21438 sats
Percentile 50%: 133834 sats
Percentile 75%: 603353 sats
Percentile 95%: 15175629 sats
Last 24 hours fee earning: 1234123 sat (0.01234123 BTC)
#LNBiG #LightningNetwork

2025-06-27 12:21:31 UTC

- reply

In short, over the past day, I managed to earn approximately 1,500 dollars in satoshis from commissions and 2,500 dollars from selling channels. The sale of channels took about 10-12 bitcoins in liquidity. This is all in the last day. Currently, the amount on the balance of all the lightning channels on my side is 183 BTC.
#nevent1q…yw3u

2025-06-27 12:17:34 UTC

- reply

A few days ago, I reduced the fees on all channels to 500 ppm. Also, in recent days, I've noticed a large number of channels being bought through the web service (for example, in the last two days about 14-15 channels were bought daily, whereas a few weeks ago, on average, 5-6 channels were bought). This might have been influenced by the fact that previously, channel openings could only occur for anchor channels, but I recently removed this restriction, and now Static Remote type channels also work for opening channels.
I also have to add liquidity to the nodes because such active channel purchases almost every day exhaust the funds that I additionally deposit.
Recently, I have been actively closing channels based on the criterion that if they haven't had at least one transaction in either direction in the last seven days. I haven't done this for more than a week, but the funds that were previously freed I moved to cold storage. Now I almost have to fund the nodes every day to meet the demand for opening channels.
Just from the last 14-15 channels that were opened daily, I was able to earn about 2.4 million satoshis, which is roughly equivalent to around 2,500 dollars.
#LNBiG #Stats #LightningNetwork #LN
#nevent1q…h4t5

2025-06-27 12:09:37 UTC

The last 24 hours of LNBϟG (2025-06-27):
Amount transactions: 7322
The sum of transfered BTC: 63.49162348
Percentile 0%: 2 sats
Percentile 25%: 65108 sats
Percentile 50%: 209711 sats
Percentile 75%: 817444 sats
Percentile 95%: 2578713 sats
Last 24 hours fee earning: 1442110 sat (0.0144211 BTC)
#LNBiG #Stats

2025-06-07 11:29:52 UTC

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

2025-06-06 16:12:51 UTC

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

2025-06-05 14:35:00 UTC

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

2025-05-27 09:11:05 UTC

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

2025-05-27 09:08:54 UTC

- reply

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.
#nevent1q…k8r4
#LightningNetwork

2025-05-27 09:04:19 UTC

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

2025-05-14 18:28:02 UTC

- reply

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).
#nevent1q…jgvt

2025-05-14 18:24:34 UTC

- reply

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
#nevent1q…fsna

2025-05-14 18:23:08 UTC

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

2025-04-26 00:13:14 UTC

- reply

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.

2025-04-26 00:09:15 UTC

- reply

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.

2025-04-25 22:29:12 UTC

- reply

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
#nevent1q…wjmz

2025-04-25 22:11:31 UTC

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.

2025-04-25 22:04:23 UTC

- reply

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.

2025-04-25 21:51:09 UTC

- reply

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.

2025-04-25 21:37:07 UTC

- reply

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

2025-04-25 21:25:52 UTC

- reply

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.

2025-04-25 21:23:05 UTC

- reply

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.

2025-04-25 21:17:20 UTC

- reply

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.

2025-04-23 04:00:36 UTC

- reply

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.

2025-04-23 03:51:25 UTC

- reply

#nevent1q…2sp0

2025-04-22 20:27:44 UTC

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

2025-04-20 11:22:25 UTC

- reply

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
#nevent1q…0xqv

2025-04-20 11:18:43 UTC

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

2025-04-02 09:13:19 UTC

- reply

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.

2025-03-16 19:52:16 UTC

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

2025-03-15 01:13:34 UTC

- reply

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.

2025-03-15 00:39:07 UTC

- reply

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
#nevent1q…j49g

2025-03-15 00:37:19 UTC

- reply

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.

2025-03-15 00:26:04 UTC

- reply

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.

2025-03-15 00:15:36 UTC

- reply

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.

2025-03-15 00:05:28 UTC

- reply

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.

2025-03-14 23:54:37 UTC

- reply

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

2025-03-14 15:03:39 UTC

- reply

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.
#nevent1q…8v9n
#nevent1q…s7ay

2025-03-14 14:56:22 UTC

- reply

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.

2025-03-14 14:27:02 UTC

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

2025-03-09 00:07:33 UTC

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

2025-03-09 00:04:55 UTC

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

2025-03-08 23:56:20 UTC

- reply

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.

2025-03-08 23:33:04 UTC

- reply

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.
#nevent1q…qv84

2025-03-08 23:30:12 UTC

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

2025-02-03 18:20:43 UTC

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

2025-02-03 15:06:50 UTC

- reply

Yes, of course, this is the sum of all statistics from all nodes, meaning I consider all nodes as one big node for myself. The only thing is that the same payment can go through two of my nodes, and thus the statistics will show double the amount. This usually happens when the path to the recipient's node goes through only my two nodes. But I can't determine the amount of such double or possibly even triple payments here. More precisely, it could be done with some degree of probability by taking into account the payment transit time and the hash of preimage. But I don't keep such statistics.

2025-02-03 15:03:02 UTC

- reply

Regarding your question, if we are talking about the capacity of a single node that is shown in the statistics on all Lightning Explorers, this is basically the sum of local balances plus the sum of balances on the other side. In other words, it is the sum of the capacity of all channels that the node has with other nodes. In the network graph, you cannot see which part of the balance one node has and which part the other node has. Therefore, if we look at the capacity of a node, it is always just the sum of all channel capacities of that node. Only public ones, because private channels are not visible in the graph, and you will not see this in the statistics in such Lightning Network Explorers as, for example, amboss.space.
As for the capacity of the entire network itself, here it is also similar, but slightly different. Here it is simply the sum of all channels that are publicly visible.
So, let's take an example. Suppose there is a #LightningNetwork consisting of only two nodes. One node has one channel with the other, and that node has the same channel with this one. That is, there are two participants in this network and one channel, one BTC. Then, if there were a viewer of the Lightning Network, we would see that node A has a network capacity of 1, node B has a network capacity of 1. The entire network capacity would also show us 1. But if we sum the capacities displayed by both nodes, we get a double value of 2 BTC. But in reality, the network #capacity is only 1.
So, if you go to some explorer now and try to sum the capacities displayed there for each node, their total sum will be exactly double the volume that is currently shown for the entire Lightning Network capacity.
Currently, the figure is about 5300 BTC. So, if you sum the capacities of all nodes, you will get approximately a figure of 10600 #BTC.

2025-02-03 14:42:37 UTC

Hello everyone! I wanted to let you know that from around mid-November to about today, which is two and a half months, I kept all my channels with zero outgoing commission (completely zero), meaning the base fee was zero and the fee rate was zero. I did this out of curiosity to see the maximum number of payments and the maximum amount of bitcoins that would pass through. After this period, I can roughly say that under these conditions I had a maximum of 30 bitcoins per day, averaging around 20 bitcoins per day, with the number of transactions at about 20,000 per day. Today I've decided to end this experiment because I don't see much point in continuing it, as it probably negatively affects other participants in the #Lightning network due to it being sheer dumping. Therefore, from today, I raised the fees, but not by much; I set the fee rate to 10 ppm and the base fee to 10 millisatoshis. It will be interesting for me to see how many payments will now go through and what the daily transaction volume will be...
#LNBiG #LightningNetwork #Stats

2025-02-03 14:35:47 UTC

- reply

Thank you for the feedback. Yes, I opened channels, but I did it with a script. I opened channels with nodes with which I did not have any channels, but which have at least 3-5 channels with other nodes. This way, I'm trying to improve connectivity within the lightning network. :)

2025-01-25 01:24:21 UTC

The nodes Edge-1 and Edge-2 have changed their IP addresses! If you are experiencing connection issues and your node shows these nodes as offline, you simply need to update their new URIs and connect to them at least once.
You can find their URIs, for example, on amboss.space, and perform a standard connect from your node.
URIs of these nodes are:
Edge-1:
0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0@213.174.156.68:9735
0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0@[2a02:b48:207:2:9735:9735:1:1]:9735
0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0@fpwyshhs72oiizwkvkkozplldd7lyk2hqtiyikv27csqv7f4j6hvimid.onion:9735
Edge-2:
03bc9337c7a28bb784d67742ebedd30a93bacdf7e4ca16436ef3798000242b2251@213.174.156.67:9735
03bc9337c7a28bb784d67742ebedd30a93bacdf7e4ca16436ef3798000242b2251@[2a02:b48:207:2:9735:9735:1:2]:9735
03bc9337c7a28bb784d67742ebedd30a93bacdf7e4ca16436ef3798000242b2251@mw2d3bedftuixrqgl4qsstqzz55k5g6ionuo2arab7bqyc2mxoihwsad.onion:9735
#LNBiG #Lightning #LightningNetwork

2024-12-29 21:46:42 UTC

The last 24 hours of LNBϟG (2024-12-29):
Amount transactions: 19752
The sum of transfered BTC: 33.09220242
Percentile 0%: 1 sats
Percentile 25%: 2500 sats
Percentile 50%: 28895 sats
Percentile 75%: 130341 sats
Percentile 95%: 585104 sats
Last 24 hours fee earning: 20 sat (#zerofee)
#Stats #LightningNetwork #LNBiG

2024-12-26 00:59:52 UTC

The last 24 hours of LNBϟG (2024-12-25):
Amount transactions: 23485
The sum of transfered BTC: 33.33525688
Percentile 0%: 1 sats
Percentile 25%: 1507 sats
Percentile 50%: 20000 sats
Percentile 75%: 101260 sats
Percentile 95%: 512900 sats
Last 24 hours fee earning: 0 sat (because #zerofee)
#LightningNetwork #Stats #LNBiG

2024-12-22 13:11:49 UTC

The last 24 hours of #LNBiG (2024-12-22):
Amount transactions: 24653
The sum of transfered BTC: 25.09640573
Percentile 0%: 1 sats
Percentile 25%: 625 sats
Percentile 50%: 2025 sats
Percentile 75%: 64168 sats
Percentile 95%: 500275 sats
Last 24 hours fee earning: 38 sat (because #zerefees)
#LightningNetwork #Stats

2024-12-20 17:26:58 UTC

The last 24 hours of LNBϟG (2024-12-20):
Amount transactions: 19497
The sum of transfered BTC: 23.81715511
Percentile 0%: 1 sats
Percentile 25%: 625 sats
Percentile 50%: 2500 sats
Percentile 75%: 80000 sats
Percentile 95%: 579594 sats
Last 24 hours fee earning: 1 sat
#LNBiG #Stats #LightningNetwork

2024-12-18 14:15:13 UTC

The last 24 hours of LNBϟG (2024-12-18):
Amount transactions: 20946
The sum of transfered BTC: 20.27933917
Percentile 0%: 1 sats
Percentile 25%: 625 sats
Percentile 50%: 1250 sats
Percentile 75%: 46546 sats
Percentile 95%: 547601 sats
Last 24 hours fee earning: 2 sat (because #zerofees for all channels)
#Stats #LightningNetwork #LNBiG

2024-12-15 21:14:57 UTC

Has anyone noticed that #LNBiG has had zero fees on all channels for over a week now? Statistics for the last 24 hours:
The last 24 hours of LNBϟG:
Amount transactions: 12359
The sum of transfered BTC: 11.42343052
Percentile 0%: 1 sats
Percentile 25%: 625 sats
Percentile 50%: 1250 sats
Percentile 75%: 40000 sats
Percentile 95%: 395799 sats
Last 24 hours fee earning: 2 sat

2024-06-06 18:27:44 UTC

- reply

The update has been finalized. All nodes are up and running. #LNBiG #Lightning #LightningNetwork
#nevent1q…60tq

2024-06-06 15:54:59 UTC

I am starting a gradual upgrade to LND 0.18.0-beta. Some servers are not working now (4 servers). After the upgrade will be upgraded the other three servers. Everything will be back to work in half an hour to an hour. Thank you for your understanding! ;)
#LNBiG #LightningNetwork

2023-11-24 22:42:11 UTC

The last 24 hours of #LNBIG (2023-11-24):
Amount transactions: 56996
The sum of transfered BTC: 29.18311177
Percentile 0%: 1 sats
Percentile 25%: 1 sats
Percentile 50%: 1 sats
Percentile 75%: 331 sats
Percentile 95%: 191243 sats
Last 24 hours #fee #earning: 61460 sat (0.0006146 BTC)
What distinguishes this day from others - even more than 50% of all transactions - with a volume of exactly 1 satoshi. As you can see, the median value is 1 sat. But the number of transactions per day is also large - usually 20-30 thousand maximum.
We can make a rough conclusion that about 30 thousand transactions today are exactly 1 sat. Maybe these are zaps with advertising to Wallet of Satoshi's wallets? I do not know, but for some reason it seems so to me (I myself receive such spam).
#LightningNetwork #stats

2023-11-16 08:54:42 UTC

Last 21 days stats (2023-11-16)
=======================
| Alias | K_Median | Volume, BTC |
| :---------------------------------------------------------------------------------------------------------------------------- | --------------: | --------------: |
| [speedupln.com](https://amboss.space/node/023631624e30ef7bcb2887e600da8e59608a093718bc40d35b7a57145a0f3db9af) | 4.0679174 | 43.03507271 |
| [MicelioMadrid](https://amboss.space/node/029b81d1aaf177fa00c1c5796360163bfa98ee4d5d0daa54c6f510d9e237f376e9) | 0.588084 | 11.59113905 |
| [Fulcrum](https://amboss.space/node/03a21a8756ffc55dd1d83a02b0cc2e163f8d041e3f56b309232e5389c66c00364c) | 0.5045894 | 2.37158235 |
| [carlslight](https://amboss.space/node/020ca6f9aaebc3c8aab77f3532112649c28a0bfb1539d0c2a42f795fb6e4c363b2) | 0.4401384 | 9.94158496 |
| [aybabtu](https://amboss.space/node/033533e2db6311c1d417d41279c067d8713ad8a7d577a0d91e65df2f6a82c5b862) | 0.3579071 | 3.79067631 |
| [rockshouse](https://amboss.space/node/031c7ecff228dfe6054307ee49c8616998af5f8d4436f13c07d211aeb6c0ec87f7) | 0.3028753 | 16.64416084 |
| [cyberdyne.sh](https://amboss.space/node/03a93b87bf9f052b8e862d51ebbac4ce5e97b5f4137563cd5128548d7f5978dda9) | 0.2844563 | 52.90010144 |
| [getalby.com](https://amboss.space/node/030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3) | 0.1799512 | 52.55067889 |
| [tippin.me](https://amboss.space/node/03c2abfa93eacec04721c019644584424aab2ba4dff3ac9bdab4e9c97007491dda) | 0.1791464 | 1.19066771 |
| [Tachyon](https://amboss.space/node/02b21730bc36061609cc1fe1bd7f5d3068e0a5e511aaf210a82c046b58020c4aa8) | 0.1267543 | 19.39741929 |
| [paxful](https://amboss.space/node/028b10be90ddfb4ef158c252163e4f340c8a093beee20427d39a0986abac58a55e) | 0.1043068 | 6.41680343 |
| [M2node](https://amboss.space/node/0335bd24a733d623205f30452c485de9c39ac3135f57679574a49a3add6bb1a050) | 0.0983475 | 1.4018918 |
| [CryptoChill](https://amboss.space/node/03df3f0a2fd6bea5429a596461ce784c922b2981ada1af89cfefcd9ccfb16c16a7) | 0.0885199 | 7.69504042 |
| [lnp2pbot-fenix](https://amboss.space/node/0380c5536d70b81137cb72fc71c262f50a3ec5a6fa9e517ef3637d889fb0b7e3db) | 0.0755771 | 1.37236277 |
| [hot-two](https://amboss.space/node/0366faf9b8693d5ca2278f6a93c393a6ca0f25ab033d13703339037bb4ee845a5b) | 0.0656868 | 1.16874305 |
| [OpenNode.com](https://amboss.space/node/028d98b9969fbed53784a36617eb489a59ab6dc9b9d77fcdca9ff55307cd98e3c4) | 0.0636686 | 4.1244081 |
| [021a272fc2d9dd07fead](https://amboss.space/node/021a272fc2d9dd07fead10372daabe0ecf23ea7cd7569f8677f890d4f9d2c26f6f) | 0.0619731 | 1.45769537 |
| [🤖RoboSats⚡ LND2](https://amboss.space/node/02187352cc4b1856b9604e0a79e1bc9b301be7e0c14acbbb8c29f7051d507127d7) | 0.0490678 | 1.85666216 |
| [kappa](https://amboss.space/node/0324ba2392e25bff76abd0b1f7e4b53b5f82aa53fddc3419b051b6c801db9e2247) | 0.0470575 | 6.92091914 |
| [Binance](https://amboss.space/node/03a1f3afd646d77bdaf545cceaf079bab6057eae52c6319b63b5803d0989d6a72f) | 0.0467993 | 41.87031825 |
| [Aldebaran](https://amboss.space/node/02bc400b9df471549c1a2071a61be27460e9726d3399370671514dd8356606bd81) | 0.0447777 | 1.31710732 |
| [Black Star ✦](https://amboss.space/node/02cc5c798fdb2361d529827ee0baf511936c231989d501de1f4e1c82a9baaaf36a) | 0.0421137 | 3.67125181 |
| [Bitrefill](https://amboss.space/node/03d607f3e69fd032524a867b288216bfab263b6eaee4e07783799a6fe69bb84fac) | 0.0413559 | 5.96504641 |
| [Sunshine Canyon](https://amboss.space/node/0362259ea579f84772508de22086fa746f6e2571f8efb4bd5ec0876bcd18b5747c) | 0.0406821 | 1.13842381 |
| [okcoin](https://amboss.space/node/036b53093df5a932deac828cca6d663472dbc88322b05eec1d42b26ab9b16caa1c) | 0.0403933 | 4.99311093 |
| [Kraken 🐙⚡](https://amboss.space/node/02f1a8c87607f415c8f22c00593002775941dea48869ce23096af27b0cfdcc0b69) | 0.0388678 | 12.49004129 |
| [okx](https://amboss.space/node/0294ac3e099def03c12a37e30fe5364b1223fd60069869142ef96580c8439c2e0a) | 0.0387621 | 32.47001027 |
| [CONFIRMO.net](https://amboss.space/node/02ff30e83896d453cfc89ff4dd06d23d793b7246f154c210324adc1d42c849ce74) | 0.0357824 | 1.64665355 |
| [Edelweiss🏔️](https://amboss.space/node/027831fdda22a3fdb95ac7f4a6348467720ba073edb61317c7bc965315c9e5bbe1) | 0.0351425 | 1.88519455 |
| [Electrum Trampoline](https://amboss.space/node/03ecef675be448b615e6176424070673ef8284e0fd19d8be062a6cb5b130a0a0d1) | 0.0336972 | 1.81067469 |
| [lndus0.zaphq.io](https://amboss.space/node/027cd974e47086291bb8a5b0160a889c738f2712a703b8ea939985fd16f3aae67e) | 0.0301307 | 2.36842331 |
| [cwallet.com](https://amboss.space/node/0371ccb71e3838984f6903b40b76581c4fceda54e22cb9c6a7d20681c036de0571) | 0.027382 | 2.25048544 |
| [deezy.io ⚡✨](https://amboss.space/node/024bfaf0cabe7f874fd33ebf7c6f4e5385971fc504ef3f492432e9e3ec77e1b5cf) | 0.023287 | 2.18162643 |
| [fixedfloat.com](https://amboss.space/node/037f990e61acee8a7697966afd29dd88f3b1f8a7b14d625c4f8742bd952003a590) | 0.0226211 | 3.26751929 |
| [allNice \| torq.co](https://amboss.space/node/0326e692c455dd554c709bbb470b0ca7e0bb04152f777d1445fd0bf3709a2833a3) | 0.0186449 | 4.46683546 |
| [The Bitcoin Company](https://amboss.space/node/026ec3e3438308519a75ca4496822a6c1e229174fbcaadeeb174704c377112c331) | 0.0177585 | 4.22739775 |
| [6102](https://amboss.space/node/03c792f6a89fefd3f1b49b3d2ce23143b6f18d36b2ccb039fdb7dbfeb29159bb70) | 0.0175683 | 1.39927039 |
| [bfx-lnd0](https://amboss.space/node/033d8656219478701227199cbd6f670335c8d408a92ae88b962c49d4dc0e83e025) | 0.0174592 | 21.37263745 |
| [Moon (paywithmoon.com)](https://amboss.space/node/025f1456582e70c4c06b61d5c8ed3ce229e6d0db538be337a2dc6d163b0ebc05a5) | 0.012995 | 1.19971759 |
| [lndwr3.zaphq.io](https://amboss.space/node/02b2ae15001601b74eee8ddbd036315c5fbd415b24f88f24d5266820169dfd13de) | 0.012497 | 1.09383042 |
| [bfx-lnd1](https://amboss.space/node/03cde60a6323f7122d5178255766e38114b4722ede08f7c9e0c5df9b912cc201d6) | 0.0118516 | 30.41617977 |
| [ed528ad49bedd1f7a638a](https://amboss.space/node/02a98e8c590a1b5602049d6b21d8f4c8861970aa310762f42eae1b2be88372e924) | 0.0114925 | 2.4840256 |
| [Babel](https://amboss.space/node/028dbc6a2716acb8941926862f888d2dac59f9277e7efb61a7046717a23f552484) | 0.0103482 | 3.1493844 |
| [Sunny Sarah ☀️](https://amboss.space/node/03423790614f023e3c0cdaa654a3578e919947e4c3a14bf5044e7c787ebd11af1a) | 0.007703 | 1.84821407 |
| [Neutronpay.com](https://amboss.space/node/02c73c8ac3f37bb28d9fc3819dc17baecdf24b137d476a2a9e22395d490d842bec) | 0.0076135 | 1.33011378 |
| [adam.masterofpearls.net](https://amboss.space/node/029efe15ef5f0fcc2fdd6b910405e78056b28c9b64e1feff5f13b8dce307e67cad) | 0.0070818 | 2.0045252 |
| [WalletOfSatoshi.com](https://amboss.space/node/035e4ff418fc8b5554c5d9eea66396c227bd429a3251c8cbc711002ba215bfc226) | 0.0063185 | 6.88496303 |
| [ACINQ](https://amboss.space/node/03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f) | 0.00583 | 3.68501095 |
| [BC.GAME](https://amboss.space/node/02c197ffa4c2aa4105dd4c4b7279ba1b9061b22910ebbfa759b0001bed9ee48a16) | 0.0047426 | 2.82024335 |
| [pedroLND](https://amboss.space/node/034a879c36f418cb5b44b6903b3c6c1cfb5f4beb1e79b9b479c040b7df9cbc56be) | 0.0046113 | 1.19334523 |
| [ln.nicehash.com [NiceHash]](https://amboss.space/node/037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba) | 0.0031926 | 1.13542036 |
| [e960fd8385a1603003727](https://amboss.space/node/039174f846626c6053ba80f5443d0db33da384f1dde135bf7080ba1eec465019c3) | 0.0031707 | 1.30858007 |
| [1sats.com⚡️lsp.flashsats.xyz](https://amboss.space/node/02e4971e61a3f55718ae31e2eed19aaf2e32caf3eb5ef5ff03e01aa3ada8907e78) | 0.0018644 | 1.5680695 |
| [southxchange.com](https://amboss.space/node/0260fab633066ed7b1d9b9b8a0fac87e1579d1709e874d28a0d171a1f5c43bb877) | 0.0010245 | 1.08815109 |
| [Boltz](https://amboss.space/node/026165850492521f4ac8abd9bd8088123446d126f648ca35e60f88177dc149ceb2) | 0.0000284 | 1.63638847 |
| [bitz23](https://amboss.space/node/023a89bcaf5d6635434af2665a7ff77cece6bb462b48ab1ee96b522505fdd44d64) | 0.0000157 | 1.15830209 |
| [Elbandi.Net](https://amboss.space/node/02246f1ced017509e85fcae75e98c6e6aa5d43450315909d73be4a0970e00f197e) | 0 | 2.42642873 |
| [Peeky](https://amboss.space/node/0250baf7a558091eb9c93f43d595b795db61bd2b55ca016d8682fd310cb1b81e6c) | 0 | 1.80939674 |
| [Sally Acorn](https://amboss.space/node/02ea8c02945fa6e6ad45f7047be0403a4e05451b74cfc08846745e220720252f70) | 0 | 1.41105265 |

2023-11-09 14:38:31 UTC

Some nodes did not work for about 8-9 hours (from 2023-11-09 03:38 UTC time). I apologize for the downtime. The reason is that one of the running bitcoin core servers did not respond, which is why the lnd servers shut down themselves. #LNBiG #Downtime #Status #LightningNetwork

2023-10-19 12:31:51 UTC

Some Nostr explorers show the incoorrect link because it's of markdown format one
Here is the separated link:
https://blogstack.io/naddr1qqyrjep5x4jnycnxqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqw4rsfpmmag
#nevent1q…sqgy

2023-10-19 12:27:13 UTC

New post from me 😉
===============
[Statistics - record volume and new channel efficiency leaders](https://blogstack.io/naddr1qqyrjep5x4jnycnxqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygy68xlcxlyx34s7mrxwdfx85r4eda09hnqg9tt2lh25jm9kzj3rlvpsgqqqw4rsfpmmag)
[Nostr note](#naddr1qq…mmag)
#LightningNetwork #LNBiG #Stats #Statistics #Lightning #Channels

2023-10-14 21:29:54 UTC

Interesting #statistics of #LNBiG for the last 24 hours.
Now I have 0/0 commissions for most channels (completely zero) - this is done for #rebalancing (only if the channel has more than 80% of the balance on my side and it's public one). If a balance is from 20% to 80% for public channels or for all private channels, then the #commission is 1000/1000 (1000 msats base fee and 1000 ppm rate or 0.1%).
Such commissions have been standing for about a week, but usually the volume of passing payments per day did not exceed 10 BTC, and commissions were not collected even $10 per day in sats (30K-40K sats).
But today's day is just very different from the days of all time. This is the first day in my memory when about $100 per day was #earned on commissions!
The last 24 hours of LNBIG:
Amount transactions: 9681
The sum of transfered BTC: 28.89890006
Percentile 0%: 1 sats
Percentile 25%: 5000 sats
Percentile 50%: 35900 sats
Percentile 75%: 149081 sats
Percentile 95%: 1007812 sats
Last 24 hours fee earning: 348034 sat (0.00348034 BTC)
Based on these data, the following conclusion can be drawn. The number of payments was as usual - it was always about 8,000-9,000 per day. But today the volume is simply colossal: 29 BTC. But what is even more important - the commissions amounted to almost $93 per day (348K sats). If you divide the commissions by volume, you get 0.012%, which is 10 times less than the commissions of balanced public channels. It can be roughly concluded that a lot of payments went through channels with zero commission, but also that 1/10 of the volume of payments went through balanced channels (or private ones) with a 0.1% commission.
I remind you that the commissions in the channel are applied at the rates of the node from which the financial flow is coming.
#Example:
That is, my commissions are applied only if the financial flow goes from my nodes to external nodes. For example, if you are connected to me as a private channel and pay the user Wallet of Satoshi, and I have a channel with their node (WoS) where the commission is 0/0, then you will pay 0 sats. But if the user of #WoS paying you into a private channel connected to me then the payer of WoS will pay 0.1% (LNBiG's fee for private channels) + fee of WoS side set on the channel between WoS and LNBiG.
#LightningNetwork #Lightning #fees #fee

2023-09-23 23:05:50 UTC

- reply

Stats at Github in Markdown format:
https://gist.github.com/LNBIG-COM/015072b3f23a3900f7fe99f2e9fde4b4
#LightningNetwork #Stats #Lightning #LNBiG

2023-09-23 23:01:16 UTC

- reply

#nevent1q…eqe2

2023-09-23 21:33:20 UTC

I would like to present to your attention my node efficiency #statistics. It is built according to my method, which, perhaps, no one has used yet. Here is his description:
For example, we build statistics for the last N days. Creating for each node an array of length N with the following structure for each element:
[ "sent sats in this day", "received sats in this day", "volume of all channels of this node in this day" ]
We take [all transactions transmitted through our nodes node for this period](https://lightning.engineering/api-docs/api/lnd/lightning/forwarding-history), and taking into account the [chan_id_in and chan_id_out](https://lightning.engineering/api-docs/api/lnd/lightning/forwarding-history#lnrpcforwardingevent) of each transaction, we form arrays for each node - that is, we adjust the values "sent sats in this day" and "received sats in this day".
It is necessary to take into account both open channels and closed ones. For open channels, it is necessary to take into account on what day they were open, and for closed ones - on what day they were open and on what day they were closed. We calculate the days taking into account chan_id of channel and the approximate fact that there are 144 blocks in a day. We take this into account to calculate the total channel volume of each day for each node ("volume of all channels of this node in this day"). We take the time (timestamp_ns) of the transaction from [forwarding event](https://lightning.engineering/api-docs/api/lnd/lightning/forwarding-history#lnrpcforwardingevent).
After all the calculations, we calculate the coefficient (K) for each day of each node: ("sent sats in this day" + "received sats in this day") / "volume of all channels of this node in this day"
This coefficient "K" shows us with what efficiency the channels were used that day. After all, you can transfer a stream of 1M sats through channel(s) with a total volume of 1M sats (K will be 1.0), and you can transfer this 1M sats through a 100K channel, but using it is 10x times more efficient (K will be 10.0)!
After all, I take the median value for each node for all days - this will be the K_target value. Then I sort all the nodes by one such value K_target - nodes with a higher coefficient get higher and are more efficient for us than with a smaller one.
And now there will be results ;-)
#LNBiG #LightningNetwork #Lightning #Stats #Algorithm

2023-09-23 20:34:53 UTC

The **third change** is that outgoing paid channels are opened with a mandatory requirement to support anchor channels from your side!
For most, this change will go unnoticed, but for the owners of the old lightning nodes software, this means that they will not be able to open a paid channel outgoing to them from the LNBiG network (of course, funds for payment will not be taken thanks to the HODL invoice).
I have to do this for the reason that in the current situation it is very dangerous to have channels without anchor support. Such channels are difficult to close if the bitcoin network fee market is growing and remains with a high fees for a very long time.
#LightningNetwork #LNBiG #News
#nevent1q…7fdw

2023-09-23 20:25:24 UTC

The other good #news is that the #Tor v3 network is already configured on [those seven nodes](https://lnbig.com/#/our-nodes) that will continue to work.
Each of the seven nodes has an IPv4 and Tor address. #IPv6 I will add later. This means that you can open channels from the Tor network to these nodes. I also added the ability to open outgoing paid channels to nodes in the Tor v3 network (previously, this required a node from the Tor network to make a connection to the my node specified in the instructions for opening a paid channel). #LNBiG #LightningNetwork
#nevent1q…ar26

2023-09-23 20:19:27 UTC

- reply

I have collected and will collect statistics on all good channels and their nodes, and then I will open channels from those 7 nodes that will work further. To do this, I will finish the scripts that will do this. I will try to make everything go as smoothly as possible.

2023-09-23 20:16:09 UTC

- reply

A little more detail about this:
I decided to reduce the number of nodes to optimize my network.
Nodes will be closed gradually, with priority on cooperative closing of channels. All channels on the closing nodes were opened more than 30 days ago. This period is prescribed in the conditions when opening the channel as the minimum period that I tried to observe when opening paid outgoing channels.

2023-09-23 20:11:49 UTC

Hello everyone!
There are some #news from [LNBiG](https://lnbig.com/):
The number of nodes of the #LNBiG network will soon be reduced from 25 nodes to 7 ones. For more than a month, the opening of channels has been working only from/to 7 nodes. The list of active nodes is visible in the ["Our nodes"](https://lnbig.com/#/our-nodes) section. #LightningNetwork

2023-06-16 13:13:43 UTC

The last 24 hours of LNBIG (2023-06-16):
Amount transactions: 8064
The sum of transfered BTC: 16.17980531
Percentile 0%: 1 sats
Percentile 25%: 15864 sats
Percentile 50%: 73069 sats
Percentile 75%: 189263 sats
Percentile 95%: 831771 sats
Last 24 hours fee earning: 16720 sat (0.0001672 BTC)
#LNBiG #Stats #Lightning #LightningNetwork

2023-06-15 17:56:42 UTC

The last 24 hours of LNBIG (2023-06-15):
Amount transactions: 10149
The sum of transfered BTC: 23.89853676
Percentile 0%: 1 sats
Percentile 25%: 11444 sats
Percentile 50%: 78706 sats
Percentile 75%: 191132 sats
Percentile 95%: 1132150 sats
Last 24 hours fee earning: 17891 sat (0.00017891 BTC)
#LNBiG #Stats #Lightning #LightningNetwork

2023-05-11 17:41:18 UTC

- reply

Except for the subtleties (translate has not been launched yet) - this site is similar in functionality to the original https://snort.social/. This can be useful for those who want to use not one #Nostr network explorer, but several. For example, if the main https://snort.social/ website does not work, you can use #LNBiG fork snort.lnbig.com with own imgproxy site ;-)

2023-05-11 17:37:04 UTC

I deployed now the fresh version of Snort web app with own imgproxy (imgproxy.lnbig.com)! Welcome to https://snort.lnbig.com ! #Nostr #Pleb #Plebstr #Snort

2023-05-10 10:02:07 UTC

The **last 24 hours** of #LNBIG (**2023-05-10**):
Amount **transactions: 6679**
The sum of **transfered BTC: 8.11484953**
Percentile 0%: 1 sats
Percentile 25%: 21 sats
Percentile 50%: 14358 sats
Percentile 75%: 100000 sats
Percentile 95%: 411354 sats
Last 24 hours **fee earning: 4651 sat** (0.00004651 BTC)
#LightningNetwork #Stats

2023-05-07 23:18:16 UTC

https://twitter.com/stephanlivera/status/1654128466575654913 #LightningNetwork #Lightning

2023-05-07 22:47:59 UTC

Today #LNBiG stats (2023-05-07):
The last 24 hours of LNBIG:
Amount transactions: 64413
The sum of transfered BTC: 13.71202436
Percentile 0%: 1 sats
Percentile 25%: 2 sats
Percentile 50%: 2 sats
Percentile 75%: 2 sats
Percentile 95%: 43235 sats
Last 24 hours fee earning: 7143 sat (0.00007143 BTC)
Now there are very low fees: 1 msat base fee / 10 ppm (0.001% from payment!). Don't forget open channels with https://lnbig.com/ nodes (when on-chain fees will be sane)! ;-)
#LightningNetwork #Bitcoin #LN #Lightning #Nostr #Plebchain #pleb

2023-04-26 17:49:17 UTC

- reply

Right now all the servers are working. Now there is a new version of LND v0.16.1.

2023-04-26 17:36:31 UTC

- reply

One shitcoin overtakes another shitcoin. What's great about that? I don't care ;)

2023-04-26 16:58:56 UTC

At the moment, the software is being updated on the servers of #LNBiG network, so all servers are being stopped and updated right now. #LightingNetwork