Skip to content

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Nov 13, 2019

This commit adds support for creating and decrypting trampoline onions.
It doesn't add support for forwarding trampoline payments yet.

This commit adds support for creating and decrypting trampoline onions.
It doesn't add support for forwarding trampoline payments yet.
@t-bast t-bast requested a review from pm47 November 13, 2019 10:22
@pm47 pm47 self-assigned this Nov 13, 2019
@t-bast
Copy link
Member Author

t-bast commented Nov 13, 2019

The code here can be tricky because we have two-levels of onion nesting (and thus two levels of decrypting then decoding) and it's easy to get confused between amounts/expiries from the outer and inner onion.
Please review carefully (especially in PaymentPacket.scala) and have a good look at the tests.
This is a necessary foundation before trampoline relay can be built, so it would be nice to progress quickly here (if we need to change the type architecture this will impact the next trampoline commits).

@codecov-io
Copy link

codecov-io commented Nov 13, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@e5060d9). Click here to learn what that means.
The diff coverage is 91.61%.

@@            Coverage Diff            @@
##             master    #1209   +/-   ##
=========================================
  Coverage          ?   76.28%           
=========================================
  Files             ?      139           
  Lines             ?     9480           
  Branches          ?      370           
=========================================
  Hits              ?     7232           
  Misses            ?     2248           
  Partials          ?        0
Impacted Files Coverage Δ
.../scala/fr/acinq/eclair/payment/PaymentEvents.scala 100% <ø> (ø)
...src/main/scala/fr/acinq/eclair/router/Router.scala 91.97% <100%> (ø)
...scala/fr/acinq/eclair/payment/PaymentRequest.scala 93.25% <100%> (ø)
...cinq/eclair/payment/receive/MultiPartHandler.scala 95% <100%> (ø)
.../src/main/scala/fr/acinq/eclair/router/Graph.scala 98% <100%> (ø)
...core/src/main/scala/fr/acinq/eclair/Features.scala 100% <100%> (ø)
...r/acinq/eclair/payment/send/PaymentInitiator.scala 100% <100%> (ø)
...re/src/main/scala/fr/acinq/eclair/NodeParams.scala 86.84% <100%> (ø)
...src/main/scala/fr/acinq/eclair/db/PaymentsDb.scala 70% <100%> (ø)
...r/acinq/eclair/payment/send/PaymentLifecycle.scala 89.9% <100%> (ø)
... and 6 more

Copy link
Member

@pm47 pm47 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass

* ChannelRelayPayload \ / \
* ________/\______________ \ / \
* / \ \ / \
* RelayLegacyPayload ChannelRelayTlvPayload NodeRelayPayload FinalLegacyPayload FinalTlvPayload
Copy link
Member

@pm47 pm47 Nov 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we rename RelayLegacyPayload -> ChannelRelayLegacyPayload?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could, but legacy already implies only channel relay. And since we're adding more dimensions to those type at some point we won't be able to mention all the dimensions inside each concrete type's name so we shouldn't strive for that 😅

We tie the type of onion packet to the payloads it may contain.
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