htlcswitch: attributable errors by joostjager · Pull Request #7139 · lightningnetwork/lnd

joostjager · 2022-11-10T15:21:02Z

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.

lnwire/features.go

htlcswitch/hop/error_encryptor.go

joostjager · 2023-01-16T11:50:40Z

routing/payment_lifecycle.go

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?

bitromortac

Great work! I think it's nice to have everything hard-coded to not reveal any fingerprint vector (except for the signal). Also, the upgrade path looks very reasonable to me, only when a majority of the network has upgraded to attributable errors (and a full attributable error route is likely), we'll request that error type (although some senders may prefer those routers already earlier). This will give a quick transition from zero senders to many senders and therefore a larger anonymity set.
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?

bitromortac · 2023-06-20T08:34:10Z

htlcswitch/switch.go

Is there a reason why log.Errorf is not used?

What extra formatting would you like to see added here? The error itself is already a full sentence. I followed the approach that was already taken in master:

lnd/htlcswitch/switch.go

Line 1311 in f1bca2a

log.Error(err)

bitromortac · 2023-06-20T08:49:32Z

htlcswitch/hop/iterator.go

This error handling seems to not belong here, right?

It is pre-existing. Maybe only ErrInvalidOnionKey is ever returned here. But not sure if we want to change this in this PR?

htlcswitch/hop/error_encryptor.go

bitromortac · 2023-06-21T08:43:56Z

htlcswitch/hop/error_encryptor.go

Perhaps we could export minPaddedOnionErrorLength and insert it here. So semantically this would tell us that we have a zero message length and zero padding?

We could, although in the rest of the lnd repo we generally calculate that number 260 from lnwire.FailureMessageLength and I aligned this new code with that.

Semantically we'll indeed communicate zero message with zero padding. But it really does not matter what we put here.

As a future step, we could define a new failure code in BOLT 04 for this, but it won't change much about the penalization.

bitromortac · 2023-06-21T08:46:26Z

htlcswitch/hop/error_encryptor.go

What are the incentives for a router to report back honestly and to not to pass on a short error? Will this node be penalized for reporting? If the node does not get penalized for reporting, any relayer could do this to penalize their neighbor?

If they pass the short error, the upstream node will replace it by a proper error and the sender will indeed penalize this node.

htlcswitch/link.go

htlcswitch/hop/iterator.go

bitromortac · 2023-06-21T09:57:38Z

lnwire/features.go

These flags are advertized by default, is it?

Yes, they are.

bitromortac · 2023-06-21T10:16:13Z

channeldb/payments.go

Out of curiosity, why is this done, to check that all parsed fields have been processed? But it's missing that check

Because right below here, the remaining records are stored as custom records. If we wouldn't delete here, the attr error record would also show up as a custom record.

joostjager · 2023-06-21T13:42:15Z

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 · 2023-06-22T09:30:42Z

Added integration test.

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 · 2023-08-08T12:28:01Z

Updated lightning-onion dependency after adding updated test vector.

To avoid a collision with the htlcswitch/hop package.

joostjager · 2023-11-06T10:34:16Z

Updated feature bit to 36/37

joostjager · 2023-11-06T20:46:21Z

htlcswitch/link.go

-		// encryption parameters.
+		// encryption parameters. Don't assume attributable errors,
+		// because first the resolution format needs to be decoded from
+		// the onion payload.


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?

This should be added to the spec.

joostjager force-pushed the fat-errors-2022 branch from 89176b5 to 7ee4126 Compare November 10, 2022 15:38

joostjager force-pushed the fat-errors-2022 branch from 7ee4126 to 929ec8b Compare November 21, 2022 08:17

joostjager mentioned this pull request Nov 21, 2022

Attribution data (feature 36/37) lightning/bolts#1044

Merged

joostjager force-pushed the fat-errors-2022 branch 3 times, most recently from 62e4317 to c80ed73 Compare December 7, 2022 11:28

joostjager changed the title ~~build: bump lightning-onion to fat errors~~ htlcswitch: fat errors Dec 7, 2022

joostjager force-pushed the fat-errors-2022 branch 4 times, most recently from 0593312 to b1185f1 Compare December 8, 2022 13:46

joostjager mentioned this pull request Dec 8, 2022

Attributable errors ACINQ/eclair#2519

Closed

joostjager force-pushed the fat-errors-2022 branch 4 times, most recently from ab1fcc2 to 61661dc Compare December 14, 2022 14:45

saubyk added this to the v0.17.0 milestone Jan 12, 2023

hieblmi reviewed Jan 15, 2023

View reviewed changes

lnwire/features.go Outdated Show resolved Hide resolved

joostjager force-pushed the fat-errors-2022 branch 2 times, most recently from 3b423ea to 87a30c9 Compare January 16, 2023 11:42

joostjager commented Jan 16, 2023

View reviewed changes

htlcswitch/hop/error_encryptor.go Outdated Show resolved Hide resolved

joostjager commented Jan 16, 2023

View reviewed changes

htlcswitch/hop/error_encryptor.go Outdated Show resolved Hide resolved

joostjager commented Jan 16, 2023

View reviewed changes

joostjager force-pushed the fat-errors-2022 branch 6 times, most recently from 77f4da8 to 7a9816b Compare January 23, 2023 12:12

joostjager force-pushed the fat-errors-2022 branch from 7a9816b to ccece71 Compare January 23, 2023 15:00

saubyk added this to the v0.17.1 milestone Jun 16, 2023

joostjager force-pushed the fat-errors-2022 branch 6 times, most recently from f25c769 to e4d3c4e Compare June 19, 2023 19:23

bitromortac reviewed Jun 21, 2023

View reviewed changes

joostjager force-pushed the fat-errors-2022 branch 2 times, most recently from a1cf55e to ef4df36 Compare June 21, 2023 13:39

joostjager requested a review from bitromortac June 21, 2023 13:40

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

saubyk requested a review from Crypt-iQ June 22, 2023 15:22

saubyk modified the milestones: High Priority, v0.18.0 Aug 4, 2023

joostjager added 3 commits August 8, 2023 14:12

htlcswitch: return error from all encrypt methods

b22b1be

htlcswitch: bump lightning-onion

e74a13a

joostjager added 3 commits November 6, 2023 11:33

htlcswitch: support fat error generation and relay

f942e03

routing/test: rename hop to mockHop

cba6e93

To avoid a collision with the htlcswitch/hop package.

htlcswitch: use fat errors as a sender

c16a9f7

Roasbeef mentioned this pull request Nov 6, 2023

Lightning Specification Meeting 2023/11/06 lightning/bolts#1116

Closed

20 tasks

joostjager commented Nov 6, 2023

View reviewed changes

Conversation

joostjager commented Nov 10, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bitromortac left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joostjager commented Jun 21, 2023

Uh oh!

joostjager commented Jun 22, 2023

Uh oh!

joostjager commented Aug 8, 2023

Uh oh!

joostjager commented Nov 6, 2023

Uh oh!

joostjager Nov 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

joostjager commented Nov 10, 2022 •

edited

Loading

joostjager Nov 6, 2023 •

edited

Loading