Good morning Andrea and ZmnSCPxj,

I wrongly assumed the channel balances needed to be known anyway to create
a route. I see
now why that is not the case and why it would scale horribly, in fact it
scales no better than
layer 1 as everyone needs to be notified of every payment. It would also
defeat effort
of keeping payments private.
This is clearly the wrong line of thinking.

This is already possible within the protocol.
> Care must be taken that `channel_update` is not spammed, which potentially
> leaks information about payments passing through the node.
> A simple heuristic would be to have a random schedule of checking the
> channel current state, sending a `channel_update` if the feerate should be
> changed, then sleeping for a random number of seconds before checking again.
> This will get you reasonably close to what you want, without too much
> leakage of payments going through you.

That would not regard the size of the payments though? A payment leaving
the balance at the far end would pay the same proportional fee as one close
to the middle.
Again fixing that issue by broadcasting each balance change wouldn't scale
well and run in the aforementioned leakage so is really a moot point.

I don't see setting the fee only regarding the initial state as obviously
beneficial to a routing node, anyway it would indeed be interesting to see
a node utilizing such a strategy, all else being equal, would outperform a
node not using it. I will implement something along this line
and see it that's the case or not.

JIT Routing from rpickhardt is more sensible as it attempts to rebalance
> only if it would benefit the node to perform the rebalancing.
> (It is more accurately named "JIT rebalancing" actually)

I will have another closer look at the JIT Routing emails.


Thanks both of you for taking the time to respond and pointing out the
clear flaws in this idea.

Best regards,
John-John Markstedt
Lightning-dev mailing list

Reply via email to