Mark Friedenbach <m...@friedenbach.org> writes: > It is not the case that all instances where you might have negative > fees would have loops.
If we don't have a cycle we can hardly talk about rebalancing channels. At that point you're paying for someone else's payment to go through your channel, and I'm unclear what the motivation for that might be. Anyway, this is still possible by communicating this out of band with the payment creator, and should not be baked into the gossip protocol itself, in my opinion. It's obscure enough to not be worth the extra effort. > One instance where you want this feature is when the network becomes > too weighted in one side of the graph. There is little you can do to prevent this: if we have a network with a small cut, with a source and sink on opposite sides of that cut, no amount of voluntary sacrifice from the nodes along the cut will have a lasting effect. The better solution would be to change the topology of the network to remove the cut, or balance traffic over it, e.g., moving a sink to the other side of the cut. > Another is when the other side is a non-routable endpoint. In both > cases would be useful to signal to others that you were willing to pay > to rebalance, and this hand wavy argument about loops doesn’t seem to > apply. I'm not sure I understand what you mean with non-routable endpoint, so correct me if I'm wrong. I'm assuming that non-routable endpoint is a non-publicly announced node in the network? In that case no fee tricks will ever get people to route over it, since they can't even construct the onion to talk to it. Notice that the payment requests allow for recipients of payments to get paid by explicitly including the necessary information to construct the onion to talk to that node. Not trying to be dismissive here, and I might be getting this wrong, so let me know if I did and what use-cases you had in mind :-) Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
