-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
channeldb+invoices: add set id index for AMP #4338
channeldb+invoices: add set id index for AMP #4338
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completed an initial pass mainly to build up my mental model on how everything will fit together in the end. So far things are looking pretty good! Will do another deeper pass once the PR leaves the draft state.
f86d202
to
6003dae
Compare
1c3edee
to
b447b1f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It definitely gets a bit heavy with all these payment types. Dropping some comments now and also need to do another pass. One question for now is how to test? Can it be done with manual custom record sending?
I think one way would be to manually create a new "compliant" key-send and verify that it goes thru the new code paths. Also that once it's settled, then the relevant fields show in in |
Mock payloads? https://github.com/lightningnetwork/lnd/pull/4338/files#diff-912650820f0598a654610a053ad16954R26 |
So currently the only way this PR is not dead code is for keysend right? |
Yes without the last commit that promotes keysend this be mostly dead code. Some minor things would not be, e.g. the way HTLC sets are now computed, but most of it would |
0d62721
to
0b91cb8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🗿
05343cd
to
355088f
Compare
@cfromknecht Please re-request review when ready. |
4270d14
to
7861ed0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🍫
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Only a last lingering question from me, when that is cleared up this LGTM 🌷
htlc.Hash) | ||
} | ||
|
||
htlcState = HtlcStateSettled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Below comments trySettle
should be no-op for non-AMP HTLCs. This looks like is not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NOP is referring to the check that we can settle the HTLC
portion, but i agree it could be more clear.
// the process by updating the state transitions for individual HTLCs | ||
// and recalculate the total amount paid to the invoice. | ||
var amtPaid lnwire.MilliSatoshi | ||
for _, htlc := range invoice.Htlcs { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Earlier we would iterate through all the invoice's HTLCs, calling cancelSingleHtlc
on those canceled by the update, and calling updateHtlc
on the rest.
With this commit we are still calling cancelSingleHtlc
on canceled HTLCs, but we are calling updateHtlc
for ALL, regardless of canceled or non-canceled.
I'm wondering if this is an intentional change.
d3657c9
to
9733cd8
Compare
Mainly affects ResolveTime which can be 0 before its settled.
Prior to AMP, there could only be one HTLC set. Now that there can be multiple, we introduce the inherent risk that we might be persisting a settle/accept of the wrong HTLC set. To migitigate this risk, we add a check to assert that an invoice can only be transitioned into an Accepted or Settled state if the specified HTLC set is non-empty, i.e. has accepted HTLCs. To do this check, we unroll the loops in UpdateInvoice to first process any added or canceled HTLCs. This ensures that the set of accepted HTLCs is up-to-date when we got to transition the invoice into a new state, at which point we can accurately check that the HTLC set is non-empty. Previously this sort of check wasn't possible because a newly added HTLC wouldn't be populated on the invoice when going to call updateInvoiceState. Once the invoice-level transition checks have completed, we complete a final pass to move the HTLCs into their final states and recompute the amount paid. With this refactor, it is now possible to make stronger assertions about the invoice and the state transitions being made by the invoiceregistry before those changes are ultimately persisted.
9733cd8
to
3663130
Compare
Type mismatch related assertion failure?
|
We also test that legacy keysend payments are promoted to AMP payments on the receiver-sdie by asserting basic properties of the fields returned via the rpc.
3663130
to
68688d6
Compare
@Roasbeef weird how this never showed up before? fixed now |
This PR adds an additional invoice index to track invoices by the set id of AMP style payments. The control paths for accepting real AMP payments are not enabled by this PR, but it does expose the necessary data structures and validation logic for accept AMP HTLC sets.
Summary of changes:
InvoiceHTLC
HTLCSet
method to compute the Accepted HTLCs belonging to a particular set idUpdateInvoice