-
Notifications
You must be signed in to change notification settings - Fork 268
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
Smarter relay logic #1011
Merged
Merged
Smarter relay logic #1011
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When relaying a payment, we look in the onion to find the next `shortChannelId`. But we may choose a different channel (to the same node), because the requested channel may not have enough balance, of for some other reasons, as permitted by the spec. Currently we limit ourselves to only two attempts: one with a "preferred" channel, and one with the originally requested channel if is different from the preferred one. This has drawbacks, because if we have multiple channels to the same node, we may not be able to relay a payment if the "preferred" channel is currently unavailable (e.g. because of an htlc in-flight value that is too high). We now retry as many times as there are available channels, in our order of preference, and if all fail, then we return a failure message for the originally requested channel.
This follows our convention of having only one `case` statement per type.
@sstone: this is best reviewed commit by commit |
Otherwise we keep retrying the same channels and end up in an infinite loop.
Codecov Report
@@ Coverage Diff @@
## master #1011 +/- ##
==========================================
+ Coverage 80.23% 81.15% +0.92%
==========================================
Files 98 98
Lines 7527 8105 +578
Branches 297 320 +23
==========================================
+ Hits 6039 6578 +539
- Misses 1488 1527 +39
|
sstone
approved these changes
Jun 3, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When relaying a payment, we look in the onion to find the next
shortChannelId
. But we may choose a different channel (to the samenode), because the requested channel may not have enough balance, of for
some other reasons, as permitted by the spec.
Currently we limit ourselves to only two attempts: one with a
"preferred" channel, and one with the originally requested channel if is
different from the preferred one. This has drawbacks, because if we have
multiple channels to the same node, we may not be able to relay a
payment if the "preferred" channel is currently unavailable (e.g.
because of an htlc in-flight value that is too high).
We now retry as many times as there are available channels, in our order
of preference, and if all fail, then we return a failure message for the
originally requested channel.