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

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:

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?