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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to