Matt Corallo <lf-li...@mattcorallo.com> writes: > Right, but there are approaches that are not as susceptible - an > obvious, albeit somewhat naive, approach would be to define a fixed and > proportional max fee, and pick a random (with some privacy properties eg > biasing towards old or good-reputation nodes, routing across nodes > hosted on different ISPs/Tor/across continents, etc) route that pays no > more than those fees unless no such route is available. You could > imagine hard-coding such fees to "fees that are generally available on > the network as observed in the real world".
This is sort of what we do already in c-lightning, namely we set up a fee budget of 0.5% and then select a random route within this constraint. On top we also fuzz the amount and other parameters within this range and similar ones in order to obfuscate the distance to the recipient, i.e., slightly overpaying the recipient, but simulating a shadow route. So while not fixed in the network, we built our own fuzzing on top of the real fees. The rationaly behind this is that users will simply not care to optimize down to the satoshi, and the resulting randomization helps privcay. We don't have real numbers but recent research results show that attempting to squeeze the very last bit of fees out has a detrimental effect on sender-receiver-privcay (surprise...). Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
