Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Trampoline/MPP DB changes #1287
This PR refactors payment structures and DB schema to correctly handle Trampoline and MPP.
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.
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.
In a follow-up PR, I will update the API to make it easier to work with MPP and Trampoline from the CLI.
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.
@@ 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.
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).