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

htlcswitch: attributable errors #7139

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

joostjager
Copy link
Contributor

@joostjager joostjager commented Nov 10, 2022

This PR adds the ability for routing nodes and nodes that are the destination of a payment to generate and relay attributable errors. This capability is signaled through a new feature bit option_attributable_errors.

Sender nodes will examine the route and request attributable errors via the attributable_errors tlv field when each node on the path supports it. There is no preference for attributable error-supporting nodes (yet).

Intermediate and final nodes report the htlc hold time in their failure message payload. The sender node only logs the hold times (Hold times: 2526/1125/0). Updating a node's reputation based on the time they held an htlc is left for a follow-up pr.

Depends on lightningnetwork/lightning-onion#60

Corresponding spec PR: lightning/bolts#1044

By default, attributable errors is only enabled for intermediate and final hops. If requested by the sender through the forward onion, they'll return attributable errors. For the sender node, the user needs to opt-in to use the feature by specifying --routerrpc.attrerrors on the command line.

@joostjager joostjager force-pushed the fat-errors-2022 branch 3 times, most recently from 62e4317 to c80ed73 Compare December 7, 2022 11:28
@joostjager joostjager changed the title build: bump lightning-onion to fat errors htlcswitch: fat errors Dec 7, 2022
@joostjager joostjager force-pushed the fat-errors-2022 branch 4 times, most recently from 0593312 to b1185f1 Compare December 8, 2022 13:46
@joostjager joostjager force-pushed the fat-errors-2022 branch 4 times, most recently from ab1fcc2 to 61661dc Compare December 14, 2022 14:45
@saubyk saubyk added this to the v0.17.0 milestone Jan 12, 2023
lnwire/features.go Outdated Show resolved Hide resolved
@joostjager joostjager force-pushed the fat-errors-2022 branch 2 times, most recently from 3b423ea to 87a30c9 Compare January 16, 2023 11:42
resolutionFormat := attempt.Route.Hops[0].ResolutionFormat

errorDecryptor := htlcswitch.NewSphinxErrorDecrypter(
circuit, resolutionFormat,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One case to consider here is that if for some reason one of the nodes had to return InvalidOnionPayload, that node wasn't able to read the resolution format. Instead if will return an old-style error that we're not decoding properly. Not sure if we care because it should only happen in case of a bug?

@joostjager
Copy link
Contributor Author

From a routing node's perspective, attributable errors may not be so nice if they know they are slow and could get penalized for it, but if the network should have fast payments this may be needed?

I think that ultimately they won't have a choice. At some point, I expect senders to avoid routing nodes that do not support attr errors.

@joostjager joostjager force-pushed the fat-errors-2022 branch 4 times, most recently from 540cb59 to a1d0805 Compare June 22, 2023 09:29
@joostjager
Copy link
Contributor Author

Added integration test.

@saubyk saubyk requested a review from Crypt-iQ June 22, 2023 15:22
@saubyk saubyk modified the milestones: High Priority, v0.18.0 Aug 4, 2023
Preparation for the instantiation of an attributable error encrypter. This gets rid
of the sphinx encrypter instantiation in OnionProcessor. This would
otherwise be problematic when an attributable encrypter would need to be
created there without having access to the error structure.
@joostjager
Copy link
Contributor Author

Updated lightning-onion dependency after adding updated test vector.

@saubyk saubyk assigned joostjager and unassigned joostjager Aug 8, 2023
@saubyk saubyk added P1 MUST be fixed or reviewed onion routing error messages labels Aug 10, 2023
@saubyk saubyk removed this from the v0.18.0 milestone Aug 10, 2023
@joostjager
Copy link
Contributor Author

Updated feature bit to 36/37

// encryption parameters.
// encryption parameters. Don't assume attributable errors,
// because first the resolution format needs to be decoded from
// the onion payload.
Copy link
Contributor Author

@joostjager joostjager Nov 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fallback to legacy format is probably fine. If this happens to be an attributable error route, the upstream node will substitute with an attributable error?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be added to the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error messages onion routing P1 MUST be fixed or reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants