📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:58:18
in reply to nevent1q…ezfy
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:58:18Event JSON
{
"id": "53095fcc4f004925456ca92ff536df083edabc771e3100932c75b95e59eb3eb1",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315498,
"kind": 1,
"tags": [
[
"e",
"d0c00323a09eb4da07465985f3eb7cafe8f64c287953e0e921fafc89b71ea038",
"",
"root"
],
[
"e",
"c66454f5ebd0066336b6d10d37f520b95205a66fa0cb73bf71b32e955cbb8855",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2020-01-29\n📝 Original message:\nMatt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e Right, but there are approaches that are not as susceptible - an\n\u003e obvious, albeit somewhat naive, approach would be to define a fixed and\n\u003e proportional max fee, and pick a random (with some privacy properties eg\n\u003e biasing towards old or good-reputation nodes, routing across nodes\n\u003e hosted on different ISPs/Tor/across continents, etc) route that pays no\n\u003e more than those fees unless no such route is available. You could\n\u003e imagine hard-coding such fees to \"fees that are generally available on\n\u003e the network as observed in the real world\".\n\nThis is sort of what we do already in c-lightning, namely we set up a\nfee budget of 0.5% and then select a random route within this\nconstraint. On top we also fuzz the amount and other parameters within\nthis range and similar ones in order to obfuscate the distance to the\nrecipient, i.e., slightly overpaying the recipient, but simulating a\nshadow route.\n\nSo while not fixed in the network, we built our own fuzzing on top of\nthe real fees. The rationaly behind this is that users will simply not\ncare to optimize down to the satoshi, and the resulting randomization\nhelps privcay. We don't have real numbers but recent research results\nshow that attempting to squeeze the very last bit of fees out has a\ndetrimental effect on sender-receiver-privcay (surprise...).\n\nCheers,\nChristian",
"sig": "aeb374ea776829d794f65045ea81333007e1f354a57380afef01da03d6260b23e2c05dd6ea18b54a16b86373ed79a77854b45b5b270ab1d1dd7e01f0e0ac6912"
}