Trampoline/MPP DB changes #1287
Merged
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
With MPP and Trampoline (and particularly the combination of the two), we need to keep track of multiple amounts, recipients and fees. There's a trampoline fee and a fee to reach the first trampoline node. The trampoline nodes must appear in the route, but not as payment recipients. Adding new fields to payment events and DB structs lets us distinguish those.
Add new colums to better handle Trampoline and MPP. Add DB migrations.
There's a race condition, we need to wait for the AuditDb to handle the payment events.
Codecov Report
@@ Coverage Diff @@
## master #1287 +/- ##
==========================================
+ Coverage 77.4% 77.46% +0.05%
==========================================
Files 143 143
Lines 10079 10082 +3
Branches 416 410 -6
==========================================
+ Hits 7802 7810 +8
+ Misses 2277 2272 -5
|
The requirement to include `var_onion_optin` in invoice feature bits was added after the first Phoenix release. Phoenix users will thus have non spec-compliant invoices in their payment history. However it doesn't hurt as long as the new invoices generated are compliant. We allow reading from the DB non-compliant invoices for backwards-compat.
pm47
reviewed
Jan 27, 2020
eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentEvents.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentEvents.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentEvents.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentEvents.scala
Outdated
Show resolved
Hide resolved
pm47
reviewed
Jan 27, 2020
eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentEvents.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentRequest.scala
Outdated
Show resolved
Hide resolved
dpad85
reviewed
Jan 28, 2020
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Show resolved
Hide resolved
* Rename finalAmount -> recipientAmount * Apply suggested code comments from PR
Instead of adding weird hooks to allow invalid invoices, we make a specific case for `var_onion_optin`. We accept invoices that don't set this field; this is a harmless spec violation (as long as we set it in new invoices).
Add migration to set it to "Standard" by default.
pm47
reviewed
Jan 28, 2020
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/relay/NodeRelayer.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/db/sqlite/SqliteAuditDb.scala
Show resolved
Hide resolved
pm47
approved these changes
Jan 29, 2020
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.
This PR refactors payment structures and DB schema to correctly handle Trampoline and MPP.
A notable change is the distinction between a target node and the final recipient.
To correctly report fees, we need to store information about the recipient, even though
we're sending a payment to the first trampoline node (our target node).
It can quickly become confusing because there are multiple amounts that appear during the payment:
I tried to make the wording uniform across the codebase to make sure we don't get those mixed up.
Those changes allow us to clean multiple temporary hacks made to support Trampoline/MPP in the first version of Phoenix.
There were also multiple places where we weren't consistent when setting parentId vs id in payment events: this is now fixed.
If you think there are other columns that can be added/changed in the PaymentsDb or AuditDb, I think it's worth adding them now to minimize migrations.
This is a big PR, but probably one of the most important ones for MPP/Trampoline support, so please take your time to review and challenge.
Even comments such as: "this part is a bit messy, please rework" are useful :).
In a follow-up PR, I will update the API to make it easier to work with MPP and Trampoline from the CLI.
E2E tests: