-
Notifications
You must be signed in to change notification settings - Fork 507
Success hold times #1261
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
Success hold times #1261
Conversation
f03a99e
to
a99b870
Compare
a99b870
to
06bb03f
Compare
Would you use a single feature bit for both? In that case, I think it would delay deployment of attributable failures. It's more work to also extend the success path. |
Yes I would use the same feature bit (which should be renamed if it applies to fulfill too?). It's barely more work and attributable failures is already delayed anyways. |
Maybe not barely more work in Eclair. You guys always have such compact ways to get things done. That's a compliment. But wouldn't say this is true for all implementations? LND team seems to be focusing on the failure case initially only. The main problem to solve is attribution for failures, and hold times are an extra. |
I agree with @thomash-acinq that it would make more sense to include in the same spec feature right now, as it is much cleaner from a protocol point of view and means we won't have to handle the technical debt of having two distinct feature bits while at some point everyone who supports one will support the other. It doesn't matter if an implementation ships with only attributable failures in |
Maybe at some point in the future, nodes may be penalized for advertising support and not generating/back-propagating attribution data on the update_fulfill_htlc. That may be a long way off though, allowing for enough time to complete the implementation?
It is the same mechanism indeed. But in LDK the implementation is also compact, so interop between Eclair and LDK seems relatively low effort to achieve. |
|
||
The `update_fulfill_htlc` message contains an optional `attribution_data` field, similar to the one used in the failure | ||
case described above. The only difference is that there is no failure message that is covered by the HMACs. With | ||
attribution data, the sender can obtain hold times as reported and committed to by each hop along the payment path. |
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 should mention blinded routes, nodes inside a blinded must not set attribution_data
.
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.
Added
I wonder what to call this feature that combines attributable failures, failure hold times and success hold times. |
I was thinking |
Merged this PR into #1044 |
Extending the idea proposed in #1044 to the success case.
LDK implementation: lightningdevkit/rust-lightning#3801