-
Notifications
You must be signed in to change notification settings - Fork 901
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
Restore payment amount fuzzing #3212
Conversation
plugins/pay.c
Outdated
@@ -1061,6 +1067,11 @@ static struct command_result *json_pay(struct command *cmd, | |||
pc->msat = *msat; | |||
} | |||
|
|||
if (*fuzzpercent > 0.0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we cap the max allowable fuzzpercent? 100% maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though there's a comment on the old version of fuzzing that mentions that the total amount doesn't exceed the allowed limit for a payment. i wonder if this is still implemented also
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm yeah I wondered to make it a do {} while (overpayment > maxfeepercent * amount)
. But the default fuzzpercent <= maxpercent
and since fuzzpercent
and maxpercent
are optional, I think someone providing them knows what they doing ?
I wonder if we should, instead, use the shadow route to fuzz? We use that to fuzz the cltv, should we use that to fuzz the amount? I'd like to generally make our shadow route stronger, and this would be a good start... |
Reading this, I said myself it would be harder to test , so it might be harder to analyze as well. I'll give it a try! |
ac6705c
to
a1e551d
Compare
Did it through shadow routing, added a FIXME in |
21e98c9
to
e458272
Compare
e458272
to
b8a2212
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, as always! Some minor changes, esp. with adding even more arguments to pay; I'm trying to avoid that as long as possible.
@@ -103,6 +103,9 @@ struct pay_command { | |||
/* Any remaining routehints to try. */ | |||
struct route_info **routehints; | |||
|
|||
/* Disable the use of shadow route ? */ | |||
double use_shadow; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this dev-only please? I don't want normal people to disable shadow routing, it's a terrible idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do
b8a2212
to
746ab85
Compare
Thanks for the review ! |
Ah I forgot the CHANGELOG trick, will do now |
When doing the random walk through the channel, we now add the fees (both the base and the proportional one) for that channel in addition to the cltv delta. Changelog-Added: Payment amount fuzzing is restored, but through shadow routing.
As Rusty pointed out to me, the gossip protocol restricts cltvs to u16 so at least we'll use this helper for them.
27fcf2d
to
642e819
Compare
Had to make a special pylightning function to avoid rewriting all calls to 'pay()' with 'rpc.call()' in the next commit..
So that we can assert payment values
642e819
to
216dd35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack 216dd35
It got stuck into the red part of a diff