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
Attributable errors (feature 36/37) #1044
base: master
Are you sure you want to change the base?
Conversation
I've started implementing it in eclair, do you have some test vectors so we can check that we are compatible? |
I don't have test vectors yet, but I can produce them. Will add them to this PR when ready. Capping the max hops at a lower number is fine to me, but do you have a scenario in mind where this would really make the difference? Or is it to more generally that everything above 8 is wasteful? |
4b48481
to
24b10d5
Compare
@thomash-acinq added a happy fat error test vector. |
24b10d5
to
76dbf21
Compare
09-features.md
Outdated
@@ -41,6 +41,7 @@ The Context column decodes as follows: | |||
| 20/21 | `option_anchor_outputs` | Anchor outputs | IN | `option_static_remotekey` | [BOLT #3](03-transactions.md) | | |||
| 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions | IN | `option_static_remotekey` | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful]| | |||
| 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] | | |||
| 28/29 | `option_fat_error` | Can generate/relay fat errors in `update_fail_htlc` | IN | | [BOLT #4][bolt04-fat-errors] | |
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.
I think this big gap in the bits has emerged here because of tentative spec changes that may or may not make it. Not sure why that is necessary. I thought for unofficial extensions, the custom range is supposed to be used?
I can see that with unofficial features deployed in the wild, it is easier to keep the same bit when something becomes official. But not sure if that is worth creating the gap here? An alternative is to deploy unofficial features in the custom range first, and then later recognize both the official and unofficial bit. Slightly more code, but this feature list remains clean.
Added fat error signaling to the PR. |
76dbf21
to
2de919a
Compare
I've spent a lot of time trying to make the test vector pass and I've finally found what was wrong:
implying that we need to concatenate them in that order. But in your code you follow a different order:
I think the order message + hop payloads + hmacs is more intuitive as it matches the order of the fields in the packet. |
Oh great catch! Will produce a new vector. |
2de919a
to
bcf022b
Compare
@thomash-acinq updated vector |
Updated LND implementation with sender-picked fat error structure parameters: lightningnetwork/lnd#7139 |
bcf022b
to
6bf0729
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.
Eclair has a basic implementation of the latest version ready: ACINQ/eclair#2519
It doesn't signal the feature yet (conflict with dual funding) and does not make use of attributable errors but should relay them correctly (compatible with the test vector).
`attributable_error` is a marker record that specifies that the failure message | ||
in the `update_fail_htlc` response should be structured as an attributable | ||
error. For the legacy format, this record should not be set. | ||
|
||
### Requirements |
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.
We need to add requirements for the reader.
It may also be useful to create a new failure code for when the downstream node sent us a legacy 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.
Requirement added for the reader.
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.
It may also be useful to create a new failure code for when the downstream node sent us a legacy error.
I don't think we can know this, can we?
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.
We can't always know for sure but the size of the packet we receive should be a good indicator, legacy error being much shorter than attributable errors.
What do you do if the downstream node returns a legacy error (or any error that's too short)? There are no payloads and hmacs to shift.
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.
Ah I see. In lightningnetwork/lnd#7139, a properly-structured all-zeroes (attributable) failure message is returned in this case. With that, the sender at least has an indication of the offending node's position, but the message itself is not defined.
Good suggestion to make that a specific error.
1947cda
to
2c3a3c9
Compare
2c3a3c9
to
8a64c6a
Compare
The spec should say what to do if
I've updated my implementation to match yours:
We could also consider an alternative system where the |
The idea would be to let all nodes just carry forward the I do wonder if this opens up attack vectors. A node forwarding an htlc and flipping
The legacy error is wrapped and the sender can interpret it, even though it went through a few attributable error nodes? I've also been thinking about this, but I doubted that it is worth the extra complexity. Given enough time, most nodes will be upgraded and mixed paths aren't needed any longer. Attributable errors are not a critical hot fix, so I think we've the time for that? |
|
||
The field `hmacs` contains truncated authentication codes for each hop, with a | ||
`um` type key generated using the above process. Regular 32 byte hmacs are | ||
truncated to the first 4 bytes to save space. |
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.
I came across the algorithm for hmac based one time passwords: https://en.wikipedia.org/wiki/HMAC-based_one-time_password#Definition
Interestingly they use a more complicated way to truncate the hash (truncate(MAC)
). It isn't clear to me that this makes it any more secure, but perhaps it is defense in depth?
Error attribution is important to properly penalize nodes after a payment failure occurs. The goal of the penalty is to give the next attempt a better chance at succeeding. In the happy failure flow, the sender is able to determine the origin of the failure and penalizes a single node or pair of nodes.
Unfortunately it is possible for nodes on the route to hide themselves. If they return random data as the failure message, the sender won't know where the failure happened.
This PR proposes a new failure message format that lets each node commit to the failure message. If one of the nodes corrupts the failure message, the sender will be able to identify that node.
For more information, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html.
LND implementation: lightningnetwork/lnd#7139
Note: the PR is currently authored as a change rather than an addition. Later on it can be converted either to an extension bolt or merged into the main spec with if..then..else sentences.