htlcswitch: attributable errors #7139
Conversation
joostjager
force-pushed
the
fat-errors-2022
branch
from
89176b5
to
7ee4126
Compare
joostjager
force-pushed
the
fat-errors-2022
branch
from
7ee4126
to
929ec8b
Compare
joostjager
force-pushed
the
fat-errors-2022
branch
3 times, most recently
from
62e4317
to
c80ed73
Compare
joostjager
changed the title
joostjager
force-pushed
the
fat-errors-2022
branch
4 times, most recently
from
0593312
to
b1185f1
Compare
joostjager
force-pushed
the
fat-errors-2022
branch
4 times, most recently
from
ab1fcc2
to
61661dc
Compare
joostjager
force-pushed
the
fat-errors-2022
branch
2 times, most recently
from
3b423ea
to
87a30c9
Compare
routing/payment_lifecycle.go
Outdated
| resolutionFormat := attempt.Route.Hops[0].ResolutionFormat | ||
|
|
||
| errorDecryptor := htlcswitch.NewSphinxErrorDecrypter( | ||
| circuit, resolutionFormat, |
There was a problem hiding this comment.
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
force-pushed
the
fat-errors-2022
branch
6 times, most recently
from
77f4da8
to
7a9816b
Compare
joostjager
force-pushed
the
fat-errors-2022
branch
from
7a9816b
to
ccece71
Compare
joostjager
force-pushed
the
fat-errors-2022
branch
from
a1cf55e
to
ef4df36
Compare
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
force-pushed
the
fat-errors-2022
branch
4 times, most recently
from
540cb59
to
a1d0805
Compare
|
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
force-pushed
the
fat-errors-2022
branch
from
a1d0805
to
91664be
Compare
|
Updated |
To avoid a collision with the htlcswitch/hop package.
joostjager
force-pushed
the
fat-errors-2022
branch
from
91664be
to
c16a9f7
Compare
|
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
This should be added to the spec.
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_errorstlv 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.attrerrorson the command line.