[Lightning-dev] Fee structure

[ZmnSCPxj]

Good morning John-John and Andrea,

>
> The current version of the spec uses source routing and that requires the sending node to attach the fees to the payment when is sent out, if the onion carries the wrong amount of fees for a channel the intermediate node should reply with a channel_update message containing the actual fees. It seems to me that you are binding the fees of a channel to its actual state but that would require to re-broadcast a channel_update for every payment that traverse the channel, so in short for every payment there would be an update being gossiped on the network and that's unpractical.

This is also very leaky.
Monitors can use the timing of `channel_update` to guess the source and destination of every payment.

If a node wishes to maintain balance on its own channels, it can simply scale its feerate depending on the channel state.
If it is already very unbalanced away from the node (the node owns less than half the capacity), then it increases the feerate.
If it is already very unbalanced towards the node, then it decreases the feerate.

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 said, I see not much point in insisting on channel balance.
While channel balance is aesthetically pleasing, it actually has little benefit to the network.
Always consider that there is almost always an alternate path, and the alternate path may have balance in the opposite direction, thus achieving "balance in the large" even if your channels are imbalanced in one way and the other.
This strikes me as focusing too much on "balance in the small".

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)
The alternative for the node if it does not rebalance the channel would be to fail the forwarding attempt.
By attempting the rebalance if the time and fee available is good enough, the node benefits as it increases the possibility of earning money (as long as a later part of the route does not fail).
It also relatively directly benefits the network, as it improves the probability of routing success (though this is tempered by the fact that in a fully-functional LN a single routing failure is a very minor event that usually does not prevent failure in-the-large).

Regards,
ZmnSCPxj