-
Notifications
You must be signed in to change notification settings - Fork 912
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Randomized overpaying (treat as routing fees) to reduce traceability #1089
Labels
Comments
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Mar 21, 2018
This obscures how far an intermediate hop is from the ultimate payee, and also obscures slightly the exact payment value. Fixes: ElementsProject#1089
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Mar 21, 2018
This obscures how far an intermediate hop is from the ultimate payee, and also obscures slightly the exact payment value. Fixes: ElementsProject#1089
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Mar 22, 2018
This obscures how far an intermediate hop is from the ultimate payee, and also obscures slightly the exact payment value. Fixes: ElementsProject#1089
ZmnSCPxj
added a commit
to ZmnSCPxj/lightning
that referenced
this issue
Mar 26, 2018
This obscures how far an intermediate hop is from the ultimate payee, and also obscures slightly the exact payment value. Fixes: ElementsProject#1089
cdecker
pushed a commit
that referenced
this issue
Mar 30, 2018
This obscures how far an intermediate hop is from the ultimate payee, and also obscures slightly the exact payment value. Fixes: #1089
Saibato
pushed a commit
to Saibato/lightning
that referenced
this issue
Apr 17, 2018
This obscures how far an intermediate hop is from the ultimate payee, and also obscures slightly the exact payment value. Fixes: ElementsProject#1089
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
BOLT#4 specifically allows overpayment of invoices of up to twice the invoice amount. BOLT #11 explicitly mentions:
My intent is the below:
fuzz
from Improve route randomization #1012, also generate a random amount to add up to some fraction of themaxfeepercent
setting to add to the destination.maxfeepercent
, reduce the fraction for overpayment and/orfuzz
(maybe even use the same variable for both?) and retry. Only raise aPAY_ROUTE_TOO_EXPENSIVE
) if both the fuzz and overpayment fraction are very close to 0.0An idea is to pay exactly when the resulting route is a single hop (i.e. direct route to destination), since nobody else will receive our onion routing message and the destination already knows how much the exact payment is (it generated the invoice...), but if we want to hide our identity from the destination, we will want to be able to pretend to be somebody else further away, meaning we should still overpay in that case.
In combination #1086, we could have "plausible" shadow routes by also overdelaying payment timeouts.
The text was updated successfully, but these errors were encountered: