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

Smarter relay logic #1011

Merged
merged 7 commits into from
Jun 3, 2019
Merged

Smarter relay logic #1011

merged 7 commits into from
Jun 3, 2019

Conversation

pm47
Copy link
Member

@pm47 pm47 commented May 20, 2019

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.

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.
@pm47 pm47 requested a review from sstone May 20, 2019 13:10
pm47 added 2 commits May 20, 2019 16:08
This follows our convention of having only one `case` statement per
type.
@pm47
Copy link
Member Author

pm47 commented May 20, 2019

@sstone: this is best reviewed commit by commit

Otherwise we keep retrying the same channels and end up in an infinite
loop.
@codecov-io
Copy link

codecov-io commented May 24, 2019

Codecov Report

Merging #1011 into master will increase coverage by 0.92%.
The diff coverage is 80.26%.

@@            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
Impacted Files Coverage Δ
...n/scala/fr/acinq/eclair/channel/ChannelTypes.scala 100% <ø> (ø) ⬆️
...c/main/scala/fr/acinq/eclair/payment/Relayer.scala 87.87% <80.26%> (+2.66%) ⬆️
...lockchain/bitcoind/rpc/ExtendedBitcoinClient.scala 91.66% <0%> (-8.34%) ⬇️
...r-core/src/main/scala/fr/acinq/eclair/Eclair.scala 46.15% <0%> (-5.46%) ⬇️
.../acinq/eclair/blockchain/bitcoind/ZmqWatcher.scala 93.13% <0%> (-3.93%) ⬇️
...scala/fr/acinq/eclair/payment/PaymentRequest.scala 90.45% <0%> (-1.61%) ⬇️
...c/main/scala/fr/acinq/eclair/channel/Channel.scala 83.2% <0%> (-0.1%) ⬇️
.../acinq/eclair/blockchain/electrum/Blockchain.scala 43.65% <0%> (+0.79%) ⬆️
...blockchain/electrum/db/sqlite/SqliteWalletDb.scala 84.52% <0%> (+1.19%) ⬆️
...e/src/main/scala/fr/acinq/eclair/api/Service.scala 72.25% <0%> (+1.31%) ⬆️
... and 6 more

@pm47 pm47 merged commit b33c9ec into master Jun 3, 2019
@pm47 pm47 deleted the smarter-relay branch June 3, 2019 17:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants