Success hold times

[joostjager]

Extending the idea proposed in #1044 to the success case.

LDK implementation: lightningdevkit/rust-lightning#3801

[thomash-acinq]

I think this should be merged in #1044. It was put in separate PR because we thought #1044 was ready but since there are still discussions around the unit to use (which also affects this PR), it would make sense to put both in the same package.

[joostjager]

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.

[thomash-acinq]

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.

[joostjager]

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.

[t-bast]

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 update_fail_htlc initially: it will simply look as if they chose to not include an attributable failure in update_fulfill_htlc, which they can always do even when they fully support the feature? As long as we've tested cross-compatibility for failure, I'd be surprised if we don't notice an issue that would affect fulfills, as it uses exactly the same cryptographic mechanism?

[joostjager]

It doesn't matter if an implementation ships with only attributable failures in update_fail_htlc initially: it will simply look as if they chose to not include an attributable failure in update_fulfill_htlc, which they can always do even when they fully support the feature?

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?

As long as we've tested cross-compatibility for failure, I'd be surprised if we don't notice an issue that would affect fulfills, as it uses exactly the same cryptographic mechanism?

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.

[thomash-acinq]

We should mention blinded routes, nodes inside a blinded must not set attribution_data.

[joostjager]

Added

[joostjager]

I wonder what to call this feature that combines attributable failures, failure hold times and success hold times. option_htlc_telemetry?

[thomash-acinq]

I was thinking option_attribution_data.

[joostjager]

Merged this PR into #1044