31 sats \ 0 replies \ @bartoli 18 Apr \ on: ⚡️ What the Drop in Lightning Nodes Means for LN's Future? lightning
If you apply basic filtering to that node count (nodes that did not update their state in the last 60 days, nodes with no advertized adddress, channels disabled on both sides,,..)
You already diminish to 3500 nodes / 16500 channels /1800BTC currently, according to my node data.
So it would be interesting to see the historic data with such filters included. Because if the number of actually useable nodes is still 1/4 of the raw advertized number, i am not sure we can actually draw advanced conclusions from it
Extracting the script that manages my ln channels params as a separate script from the code of the server of my ln node advisor, so I can share it on github
Thanks for the work, i will re-read it again when i have more time:
Two questions:
- For the 'Betweenness centrality' in the paper, what does 'shortest path' mean in your context? Is it really in terms of number of hops? I have found that using this notion of 'shortest path' is quickly limited in what information it brings, since it considers that every channel is equal (in capacity to route any amount, in any direction, at any moment of time, and in cost to route that payment). We are not in a purely mathematical graph, but on the lightning network. For me, it seems that shortest path in LN should more be a measure of 'cheapest path', AND, 'path that can actually route the payment', not just a number of hops. (Spoiler alert about what might be in next part of my articles about what i learnt building a LN channel advisor i guess)
- Is that historical channel update data openly available so i can also use it for my LN channel advisor, instead of just relying on immediate LN network state?
I did not put the git repo on a public server no. I would have to cleanup the code a little, but i have nothing against it.
Do you mean, so that i can prove that it is not biased to making people opening channels that are in my interest? Maybe it's a good reason. I have to admit i have trouble personally with running things such as rebalance-lnd, lndg, autopilot, because i want to be sure i understand what they actually do and that it conforms to what i would want to do with the sats i have in my channels
What about when the force close transaction has no anchor outputs (don't ask my why it doesn't, i have not idea), so bumpclosefee cannot CPFP it?
Is accelerating the transaction the only way?
Building the core codebase for my disaStr project. The first result of this should be a nostr-based peer system so decentralized protocols can use peers as relays, to avoid having a need for an open port on all nodes, making onboarding more user friendly
Sorry i did not see the reply.
This was in the early code for my lightning node channel advisor (www.lnshortcut.ovh). But as i found out there was actually no 'island', i just abandonned that code.
If a channel has a much better balance of incoming and outgoing flow which can be tweaked by changing the rates so that it never gets too heavy on one or the other side, then the risks go way down, and the necessary fee rates tends towards zero, because eventually you'll move enough traffic to cover all the costs over time. These types of channels are the healthiest and most sustainable.
That will not magically make traffic appear in the other direction, just drain the channel slower
And it's practically impossible to predict or otherwise plan ahead to choose channels that will likely have such bi-directional flow. Experimenting on LN is expensive, because channel closes are expensive. And people generally don't have or want to risk tons of BTC for this purpose, even if it's potentially profitable. I wish I knew how many LN nodes out there were profitable, but I would guess close to 0.01%. Because it's a very hard problem to solve which channels are the most ideal to open and will have sufficient bi-directional flow. And you can't really solve that by simply opening up channels in one particular way, because I believe, over time, it will always tend towards an unbalanced situation, at which point, the only real rebalancing option you have is to close the channels that are stuck at 99% and 1% and haven't moved any sats.
What i do to choose new channels:
- Take the network graph from my node, and apply some filters
- Analyze, for a given payment size, how many nodes it can reach in both directions (inbound, outbound) for a given max cost.
- Then, for each candidate node, look how many more nodes can be reached (cost becomes less than the max cost, or nodes that could be reached but cost is now slower) in each direction
- For each candidate, i take their 'new node reach' in the worst direction, order that
- And finally select the one that will bring more nodes 'in reach' in the 'worst direction'.
That way, i choose peers that are not 'the best' connected, but will have a better balance of new inbound/outbound traffic
But i can't really claim it works, my node is still too small for this strategy to trigger the organic balancing i hope it could bring
People are not updating max_htlc_msat to exactly the channel balance. And they are not doing it after every route on all channels. They could have router 0 or 1000 payments between updates. You can get 'some insights', but not really know what they route
Last time I looked from the network graph, more than 99% of the nodes were connected together.
I at some point thought that finding those 'islands' was a good idea, to get lots of traffic by being the bridge between them, so I built a tool to check that
The few that are not connected keep it that way for a reason.
Writing the 'Identity manager' class for my project, to generate multiple nostr like identities to represent various objects.
If some one has pointers to easy to reuse c/c++ code for
- Genrating true random secrets for really random privkeys
- decrypting a mesage signed with a nostr privkey to check the sender pubkey
That would be appreciated
I was thinking of doing something similar, with nostr as gossip, where simple nostr events would allow to find who has/wants what in the most anonymous way possible, then data exchange is done by direct encrypted connections. It's still in draft in my head for now.
There is also a 5M sat bounty for a nostr based file sharing platform here:
https://bountsr.org/p2p-filesharing/
Thanks!
Does that mean that if i define my own kind, other relays can simply choose to not relay this one if they don't want to, and i don't need to have my own 'nostr mainnet' to avoid overloading them?
Not much really. I think noone tried the recent additions to my lightning node channel advisor. I know I could do a lot to improve the ux, but with no users and little free time, I don't really have much incentive to make it print more than raw analysis results. Thinking about having my own lightning node ranking system. I don't know if it will be useful either, but at least I can see the progress of my own node after each 'ew channel recommended by my advisor.
Also thinking about the new server to host the lightning node after the original server died, to replace the temporary one currently in use.
And letting some other 'big' project idea mature in my brain