Skip to content
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

Closed
ZmnSCPxj opened this issue Feb 24, 2018 · 0 comments
Closed

Randomized overpaying (treat as routing fees) to reduce traceability #1089

ZmnSCPxj opened this issue Feb 24, 2018 · 0 comments

Comments

@ZmnSCPxj
Copy link
Collaborator

BOLT#4 specifically allows overpayment of invoices of up to twice the invoice amount. BOLT #11 explicitly mentions:

the payee SHOULD accept up to twice the expected amount, so the payer can make payments harder to track by adding small variations.

My intent is the below:

  1. In combination with fuzz from Improve route randomization #1012, also generate a random amount to add up to some fraction of the maxfeepercent setting to add to the destination.
  2. If the resulting route exceeds the actual desired payment by more than maxfeepercent, reduce the fraction for overpayment and/or fuzz (maybe even use the same variable for both?) and retry. Only raise a PAY_ROUTE_TOO_EXPENSIVE) if both the fuzz and overpayment fraction are very close to 0.0

An 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.

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
Projects
None yet
Development

No branches or pull requests

1 participant