Who said nostr was supposed to be used only for social networks?

Thanks everyone, lots of interesting things to think about.

Indeed, new channels don't actually affect me as long as liquidity is on their side. And when they start having some of my liquidity on them, i should decide if this is really a problem for me, and what i will do to limit it it if it is. The problem i was seeing is that if there are too much remote channels, thay could each potentially stuck my liquidity on them, unbalancing the other channels i carefully selected to be somewhat orcanically rebalancing as long as they have balanced liquidity

I think i will start by modifying my peer selection tool, to not only find interesting new peers, but also evaluate which existing peers are not interesting enough. So i can close some channels or reallocate their balance to other ones.

By then it should be clearer in my mind what i should do each time i have new funds to put on LN

Even the early electronics where quite différent. I have had to replace the 'logic' that drove the electric motors of a drilling rig built only 35 years ago. About a hundred of buttons and seniors came, as as many wires, 24v or 0v for 1 or 0, in 4 electrical cabinets, each bigger that a fridge. In there, there where hundreds of big old relais, doing all the AND, OR, NOT, boolean operations to combine all those conditions All this for 4 motors. We replaced it by a simple industrial PLC, about the size of à computer, smaller that just the terminals the connect all the inbound and outbound signals. It was fun retro engineering the logical conditions from the relay wiring, then rewriting them

If you need help on getting faster results, i'd ve happy to help! Mine (www.lnshortcut.ovh) used to take 30+ secondes to give recommandations, and now does yet more things in less that 1 second. Optimizing it was the most fun part!

You can use lnshortcut.ovh as another metric. It is originally for routing nodes to find good peers to connect to, but you can also use it with a routing nodes' pubkey, a transaction size and max fee to test, and get an idea of how much of the oublic network that transaction could reach in each directions from that routine node

A source channel is a channel that has mot liquidity local, because there are not enough routes that find it interesting as an outbound channel with its current outbound fee. I agree that to be able to have a big discount on the sink's inbound feerate you need big enough fees on the outbound channels routes will use (i already thought about it too, see #537007). But if you increase the outbound fee of a channel that is a source (that already has not enough routes as outbound channel with it's current outbound fee) to 'increase' the discount, that discount is cancelled by the increase of the outbound fee on the source channel. So routes that come in from the sink, and out by the source channels are still as uneconomical as before. So the increased discount on the sink only brings something for other outbound channels that actually route with their higher outbound fee. For the source channel who has had an outbound fee increase, it is actually not encouraging more transaction that would rebalance the sink channel, while reducing even more the few transactions that used the source channel as output, keeping it even more stuck as a source So for me, the only channels where you could consider increasing the outbound fee to increase the impact of the discount are actually all the channels that are NOT sources

I am not saying this is not the case. I'm saying that in this paragraph, to my understanding, the author should advise the opposite : low outbound fee on the source channel, not a high one . It's the sink that should have a high inbound fee.

For the last part, i might have written too fast, indeed, the inbound discount on the sink channels is good

'''The way to properly use it is to set relatively high outbound fee rates for source channels, and give equally high discounts to the most stubborn sinks. A fee management algorithm should be able to set such inbound discounts automatically when the liquidity dips below a pre-set threshold. Of course, currently this will only work if the mission control is done by another LND 0.18 node.'''

Isn't it the opposite? The fee taken for a route is the outbound channels feerate. A channel is not a source because it has low fees, but because it is the inbound channel for routes that go throuh a cheap outbound channel, so it ends up with lots of local balance. Increasing it's fees would then reduce even more the routes it would do the other way, so it would stay a source. And the discount on the sinks would make it even more a sink

I think the author should clarify more between the externat remote IP of your internet connections and the IP of your node on your local network. People might understand that you advise them to open the rpc and rest ports on the internet

I started with one 400W panel to try this year. It's those panels that you can simply put in your garden, plug in a regular outlet, and it will inject directly in the house. Nothing goes back to the network as long as it is consumed locally first, so no need to have a specific contract to sell it, you will just lose the occasional extra watts that are reinjected in the network bt not paid. You just declare them to the enrgy distribution company. Those panels will however only work if you are connected to the network (for example, to avoid injecting power on the network while there is an outage and risking the life of the people working on the power lines)

That panel should produce about 500kWh per year where i live, for an estimated 100$/year at my current energy prices, and should be ROId in 7 years.

On a few sunny days where nothing is running at home, there will occasionally be more production than the house consume at noon.

For the next panel, there should be more energy that is not consumed at peak sun time of sunny days, so i considered buying the model with an integrated battery. But After calculations for my cases, the 'not wasted' extra enrgy would cost more than the current energy prices on the network. So either i'll buy a second one without battery and mine something with the extra power, or i'll just keep only one and just buy 1% of bitcoin with the money, i have not yet decided.

One small detail to know with those panels. They give you a 'smart plug' that will measure how much is produced, and connect to your wifi so yu can see the data in an app. That thing consumes at least 5W consistently. My single pannel should produce on a yearly average 50W. So by simply using it on a single panel setup, you are already losing 10% of your production! I keep it because it is a cheap way to know from wherever i am if there is still power and internet at home, for me this is an important information because i run things at home. But some people might have an interest to not use it and trade the loss of production monitoring for more 'usefull' power production

Thanks!

Any ETA for the ability to edit LND 0.18's negative inbound fees in RTL?

So, what is the 2-word descriptions for a few other countries in this book?

And the ability to set sweeper max feerate! I lost 400$ a few days ago because my node decided to do two sweep txs with 1156 fee..

@C_Otto side question for those of us who develop node managment tools: did lnd also add/update a lncli/rest api so we can check if the feature is supported and enabled by the node, or do we have to rely on lnd version for now?

There is one thing I will try with this update. The current fee strategy of lnshortcut.ovh is basically 0 base fee and 1 ppm for most channels, and 0 ppm if some channels need more inbound balance. What I want to try is to increase fees on channels that are sinks, up to to a point they still route a lot (let's call it a feerate of N ppm), but in the mean time, have a fee rate on source channels of -(N-1) ppm. So in the end, my effective feerate is still 1 ppm, but I get more traffic in the direction that didn't route, so also more traffic in the other direction that receives a fee

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