Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-29 📝 Original message: Matt Corallo <lf-lists at ...
📅 Original date posted:2020-01-29
📝 Original message:
Matt Corallo <lf-lists at 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
📝 Original message:
Matt Corallo <lf-lists at 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