Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-15 📝 Original message: Hi ZmnSCPxj, Since, B ...
📅 Original date posted:2019-06-15
📝 Original message:
Hi ZmnSCPxj,
Since, B cannot report the `update_fail_htlc` immediately, its timer should
> still be running.
> Suppose we counted only up to `update_fail_htlc` and not on the
> `revoke_and_ack`.
> If C sends `update_fail_htlc` immediately, then the
> `update_add_htlc`->`update_fail_htlc` time reported by B would be fast.
> But if C then does not send `revoke_and_ack`, B cannot safely propagate
> `update_fail_htlc` to A, so the time reported by A will be slow.
> This sudden transition of time from A to B will be blamed on A and B,
> while C is unpunished.
>
> That is why, for failures, we ***must*** wait for `revoke_and_ack`.
> The node must report the time when it can safely propagate the error
> report upstream, not the time it receives the error report.
> For payment fulfillment, `update_fulfill_htlc` is fine without waiting for
> `revoke_and_ack` since it is always reported immediately upstream anyway.
>
Yes, that is a good point. C hasn't completed its duty until it sends
`revoke_and_ack` indeed.
> > I think we could indeed do more with the information that we currently
> have and gather some more by probing. But in the end we would still be
> sampling a noisy signal. More scenarios to take into account, less accurate
> results and probably more non-ideal payment attempts. Failed, slow or stuck
> payments degrade the user experience of lightning, while "fat errors"
> arguably don't impact the user in a noticeable way.
>
> Fat errors just give you more information when a problem happens for a
> "real" payment.
> But the problem still occurs on the "real" payment and user experience is
> still degraded.
>
> Background probing gives you the same information **before** problems
> happen for "real" payments.
>
With probing, I was thinking about probing right before making the actual
payment, so not a process that is continuously running in the background. I
am not sure how that would scale, everyone (assume mass adoption) probing
the whole network. Also, for private channels, nodes may put rate limits in
place or close channels that are the source of many failures. Then end
points with only private channels like a mobile app wouldn't be able to
probe effectively anymore.
I do think probes are useful, but would only use them sparingly. Sending a
probe before the real payment surely helps to mitigate certain risks. But
then I'd still prefer to also have fat errors. To get maximum value out of
the probe and minimize the number of probes required. Functionally
speaking, I don't see why you wouldn't want to have that extra information.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190615/82a4f1d1/attachment.html>;
📝 Original message:
Hi ZmnSCPxj,
Since, B cannot report the `update_fail_htlc` immediately, its timer should
> still be running.
> Suppose we counted only up to `update_fail_htlc` and not on the
> `revoke_and_ack`.
> If C sends `update_fail_htlc` immediately, then the
> `update_add_htlc`->`update_fail_htlc` time reported by B would be fast.
> But if C then does not send `revoke_and_ack`, B cannot safely propagate
> `update_fail_htlc` to A, so the time reported by A will be slow.
> This sudden transition of time from A to B will be blamed on A and B,
> while C is unpunished.
>
> That is why, for failures, we ***must*** wait for `revoke_and_ack`.
> The node must report the time when it can safely propagate the error
> report upstream, not the time it receives the error report.
> For payment fulfillment, `update_fulfill_htlc` is fine without waiting for
> `revoke_and_ack` since it is always reported immediately upstream anyway.
>
Yes, that is a good point. C hasn't completed its duty until it sends
`revoke_and_ack` indeed.
> > I think we could indeed do more with the information that we currently
> have and gather some more by probing. But in the end we would still be
> sampling a noisy signal. More scenarios to take into account, less accurate
> results and probably more non-ideal payment attempts. Failed, slow or stuck
> payments degrade the user experience of lightning, while "fat errors"
> arguably don't impact the user in a noticeable way.
>
> Fat errors just give you more information when a problem happens for a
> "real" payment.
> But the problem still occurs on the "real" payment and user experience is
> still degraded.
>
> Background probing gives you the same information **before** problems
> happen for "real" payments.
>
With probing, I was thinking about probing right before making the actual
payment, so not a process that is continuously running in the background. I
am not sure how that would scale, everyone (assume mass adoption) probing
the whole network. Also, for private channels, nodes may put rate limits in
place or close channels that are the source of many failures. Then end
points with only private channels like a mobile app wouldn't be able to
probe effectively anymore.
I do think probes are useful, but would only use them sparingly. Sending a
probe before the real payment surely helps to mitigate certain risks. But
then I'd still prefer to also have fat errors. To get maximum value out of
the probe and minimize the number of probes required. Functionally
speaking, I don't see why you wouldn't want to have that extra information.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190615/82a4f1d1/attachment.html>;