Skip to content
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

Closed

Conversation

joostjager
Copy link
Contributor

@joostjager joostjager commented Jun 11, 2019

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.

@joostjager joostjager requested a review from cfromknecht June 11, 2019 06:58
@joostjager joostjager force-pushed the expiry-info-leak branch 2 times, most recently from 85c5b0f to d571917 Compare June 12, 2019 10:19
@joostjager
Copy link
Contributor Author

Added commit lnwire+htlcswitch+routing: report height for invalid payment details to show what we can do with lightning/bolts#608

@Roasbeef Roasbeef added P2 should be fixed if one has time privacy General label for issues/PRs related to the privacy implications of using the software routing labels Jun 18, 2019
@joostjager joostjager force-pushed the expiry-info-leak branch 3 times, most recently from bd91412 to df0b256 Compare June 25, 2019 14:14
@wpaulino wpaulino added this to the 0.7.1 milestone Jul 2, 2019
@wpaulino wpaulino added the v0.7.1 label Jul 2, 2019
Copy link
Contributor

@cfromknecht cfromknecht left a 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

@@ -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),
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@joostjager
Copy link
Contributor Author

I already renamed the failure message type, but changed the failure code itself now too.

@joostjager joostjager requested a review from cfromknecht July 4, 2019 10:20
@Roasbeef Roasbeef modified the milestones: 0.7.1, 0.8 Jul 9, 2019
@wpaulino wpaulino removed the v0.7.1 label Jul 9, 2019
@Roasbeef
Copy link
Member

Roasbeef commented Aug 5, 2019

Looks like we can move forward with this after the latest spec meeting.

@joostjager joostjager requested a review from Roasbeef as a code owner August 6, 2019 08:45
@joostjager joostjager force-pushed the expiry-info-leak branch 3 times, most recently from e314e53 to 3ee2264 Compare August 6, 2019 09:40
@Roasbeef Roasbeef removed their request for review August 15, 2019 23:53
@joostjager joostjager changed the title lnwire+htlcswitch+routing: report and interpret incorrect_or_unknown_payment_details height [no review] lnwire+htlcswitch+routing: report and interpret incorrect_or_unknown_payment_details height [don't review] Aug 23, 2019
@joostjager joostjager force-pushed the expiry-info-leak branch 3 times, most recently from 7f7cd72 to 576f3fe Compare September 9, 2019 11:03
@joostjager joostjager changed the title lnwire+htlcswitch+routing: report and interpret incorrect_or_unknown_payment_details height [don't review] lnwire+htlcswitch+routing: report and interpret incorrect_or_unknown_payment_details height Sep 9, 2019
@joostjager joostjager added blocked and removed blocked labels Sep 9, 2019
@joostjager joostjager requested a review from Roasbeef September 9, 2019 11:07
@joostjager
Copy link
Contributor Author

This is now rebased and can be re-reviewed

@cfromknecht
Copy link
Contributor

@joostjager needs rebase

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.
@wpaulino wpaulino removed the v0.8.0 label Sep 17, 2019
@wpaulino wpaulino modified the milestones: 0.8.0, 0.9 Sep 17, 2019
Copy link
Member

@Roasbeef Roasbeef left a 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 {
Copy link
Member

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.

@Roasbeef Roasbeef modified the milestones: 0.9.0, 0.10.0 Jan 7, 2020
@Roasbeef Roasbeef added limbo and removed v0.9.0 labels Jan 14, 2020
@joostjager
Copy link
Contributor Author

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.

@joostjager
Copy link
Contributor Author

Closing this for now. The approach in this PR isn't the easiest. The mission control store needs to be updated and for SendToRoute calls we don't even know the intended final cltv delta, making it hard to interpret the failure result.

Now that we have the payment address to block probing, it seems like a better option to revive FinalExpiryTooSoon again.

@joostjager joostjager closed this Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 should be fixed if one has time privacy General label for issues/PRs related to the privacy implications of using the software routing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants