-
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
lnwire+htlcswitch+routing: report and interpret incorrect_or_unknown_payment_details height #3186
Conversation
0d70f73
to
c125c5d
Compare
85c5b0f
to
d571917
Compare
Added commit |
d571917
to
dd3041e
Compare
bd91412
to
df0b256
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.
nice changes! nice to see some of the cancel reasons being removed and simplifications of the error responses
invoices/invoiceregistry.go
Outdated
@@ -621,15 +645,17 @@ func (i *InvoiceRegistry) NotifyExitHopHtlc(rHash lntypes.Hash, | |||
debugLog("expiry too soon") | |||
|
|||
return &HodlEvent{ | |||
Hash: rHash, | |||
Hash: rHash, | |||
FinalCltvDelta: expiry - uint32(currentHeight), |
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.
is primary reason for doing this that it doesn't require database changes? and defer storing accepted height
to do in one refactor?
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.
AcceptedHeight
is complicated because there can be multiple held htlcs with different accept heights. This is meant as a stop gap until we have an invoice registry that tracks each htlc paying to an invoice.
df0b256
to
7f7e8b0
Compare
I already renamed the failure message type, but changed the failure code itself now too. |
7f7e8b0
to
6e46c58
Compare
Looks like we can move forward with this after the latest spec meeting. |
6e46c58
to
51f90d2
Compare
e314e53
to
3ee2264
Compare
7f7cd72
to
576f3fe
Compare
576f3fe
to
567fd2c
Compare
This is now rebased and can be re-reviewed |
@joostjager needs rebase |
567fd2c
to
d0ce75e
Compare
The original intention of this failure code enum was to match the integer values as defined in the spec. Unfortunately this wasn't done correctly. Changing the assigned numbers would be a breaking change. For now we just update the comment.
d0ce75e
to
e65a7be
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.
Change reads well, one final comment re migrations (new suggested policy, and possibly starting to migrate mission control after all).
// which final cltv delta values are stored too. Because mission control data is | ||
// not critical we opt for simply clearing the existing data rather than a | ||
// read/update/write migration. | ||
func migrateMcFinalCltv(tx *bbolt.Tx) error { |
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.
Shall we commence the new migration package proposal with this PR? As it's the first target migration for 0.9, and the migration itself is pretty light.
More on topic for this PR: perhaps we should just start migrating this data? It's not critical, but certain services could see degradation in service quality after updating beyond this PR. We currently don't have a way of loading external data, so there's no way for them to preserve the mission control data if they consider it precious enough to do so.
I need to figure out how to continue with this PR. Now that we have the payment secret, it may again be possible to return more failure details to the sender. |
Closing this for now. The approach in this PR isn't the easiest. The mission control store needs to be updated and for Now that we have the payment address to block probing, it seems like a better option to revive |
This pr extends failure result interpretation by inspecting the height at which the receiver accepted the htlc. This allows senders to distinguish between incorrect details and delays on the forward path.