LNBϟG

Official LNBϟG account in Nostr ;-) I like zaptoshis! :)
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

NIP-57 Address

lnbig@getalby.com

Profile Code

nprofile1qqsf5wdlsd7gdrtpakxvu6jv0g8tjm67t0xqs2kk4lw4f9ktv99z87cpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz9mhxue69uhkummnw3ezuamfdejj7h0qup3

Publishing to

relay.nostr.band

nostr.wine

relay.damus.io

Author Public Key

npub1ngumlqmus6xkrmvvee4yc7swh9h4uk7vpq4ddt7a2jtvkc22y0asrse3pv

Show more details

Last Notes

2025-05-14 18:28:02

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

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

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

- 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

- 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

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

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

- 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:37:07

- 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

- 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

- 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

- 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

- 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-22 20:27:44

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

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

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

- 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-15 00:39:07

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

- 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

- 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

- 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

- 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-09 00:07:33

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

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:30:12

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 14:42:37

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

2024-12-26 00:59:52

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-18 14:15:13

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

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

2023-11-09 14:38:31

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-09-23 21:33:20

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

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

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:16:09

- 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

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-05-11 17:41:18

- 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

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-07 22:47:59

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-01 22:35:24

- reply

🫂

2023-03-10 14:44:13

- reply

Sometimes the network graph of LN has old IPs for some nodes. It's problem of v0.15.5 of LND. I hope that v0.16 will resolve this problem (I often moved nodes to other hardware because I am doing now an upgrade of servers hardware)

2023-03-10 11:21:34

- reply

Everything was ok yesterday. Please more info if you have a problems now

2023-03-03 19:27:01

The last 24 hours of LNBIG (2023-03-03):
Amount transactions: 10181
The sum of transfered BTC: 19.80413689
Percentile 0%: 1 sats
Percentile 25%: 10000 sats
Percentile 50%: 47978 sats
Percentile 75%: 160001 sats
Percentile 95%: 930932 sats
Last 24 hours fee earning: 36196 sat (0.00036196 BTC)

2023-03-01 15:43:58

- reply

The Lightning protocol operates in millizatoshis. Including the LNURL (and NIP-57). But for some reasons unknown to me, the developers of LNURL solutions often ignore this and round it up to a thousand (1 sat). I patched the snort a little with my hands so that I could specify fractional parts. More than 90% of NIP-57 providers do not work, but the jp55 lightning address works with msats. And I sent to him 1/1000 of satoshi 😃

2023-02-28 18:54:03

GE 😄

2023-02-28 18:53:30

https://nostr.build/i/nostr.build_eba6dff76769743f98029e2d48431f3693ed5de6f3a51286bf76d82d1d8aeddf.png

2023-02-28 18:38:41

- reply

NO!

2023-02-28 18:37:16

https://nostr.build/i/nostr.build_41942ff5b5ee6e78504e392cdfb28905bf8441b56eb4598ed503328bd52c43ea.png

2023-02-28 14:52:33

- reply

It seems to me that the best thing so far is for the client programs of Nostr to offer simple settings to go only through Tor, and in no other way. #[5] ?

2023-02-28 14:49:42

- reply

And what about mobile devices? For example, if the Nostr client periodically loads feeds (for a certain npub through a "subscription")? Have a VPN enabled all the time? And if you need to turn it off sometimes? However, in Android, you can specify that certain applications go only through a VPN. But it's all complicated for the average user.

2023-02-28 13:56:21

- reply

Just imagine that any oppositionist of the government has a Nostr account. In this case, it is enough for the authorities to put in Login his well-known key, go in and see all the keys (nostr accounts) of those who wrote to him personally in correspondence. Next, it is a matter of technique to calculate the IP addresses of those who wrote to him. Especially if you deploy a network of fake relays in order to collect data.

2023-02-28 13:52:57

- reply

If anyone wants to personally check - go to https://snort.social/, click "Login" and specify any npub* key - you will see everything as the owner of the public key would see, except that you will not be able to read the text of personal correspondence with anyone. It's not very nice to find out about it ;-/

2023-02-28 13:46:12

- reply

Given the specifics of Nostra, that it is impossible to delete data is even more dangerous. For example, you wrote to someone in private correspondence and anyone can then see with whom and when you corresponded. This is, in fact, public metadata in plain sight... I think in the future we will learn about more than one case when they were arrested for it (China, Russia, etc..)

2023-02-28 13:43:58

To be honest, I am concerned about the anonymity in Nostr. If you suddenly don't know, then when you view your account through the web version, then:
1) Every relay knows your referrer (site name)
2) Relay knows your IP address, and probably your npub (when there is a request to subscribe to a feed about a certain user - about you yourself)
Also, if you correspond with someone in a personal chat, everyone can find out with whom and how many messages (only they do not know the text of the correspondence). All this is quite dangerous for those who want to remain anonymous. For example, in totalitarian regimes it is very dangerous.

2023-02-28 13:33:21

The snort web interface (i deployed it at localhost from github sources) works very smooth! It's best web interface by my opinion

2023-02-28 13:27:58

Today LNBIG stats (2023-02-28):
The last 24 hours of LNBIG:
Amount transactions: 8291
The sum of transfered BTC: 10.53969468
Percentile 0%: 1 sats
Percentile 25%: 10000 sats
Percentile 50%: 37001 sats
Percentile 75%: 70000 sats
Percentile 95%: 341022 sats
Last 24 hours fee earning: 15609 sat (0.00015609 BTC)

2023-02-27 14:51:40

Thank you #[0] for NIP-05! Now it looks very cool!
https://i.imgur.com/WvsPO5A.jpg

2023-02-16 13:41:29

- reply

PV 🌞