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
Good morning Joost,
> Yes that is accurate, although using the time difference between receiving
> the `update_add_htlc` and sending back the `update_fail_htlc` would work too.
> It would then include the node's processing time.
It would not work safely.
A node can only propagate an
Hi Bastien,
> What about having each node add some padding along the way? The erring
> node's padding should be bigger than intermediate nodes' padding (ideally
> using a deterministic construction as you suggest) so details need to be
> fleshed out, but it could mitigate even more the
Hi ZmnSCPxj,
> > That is definitely a concern. It is up to senders how to interpret the
> received timestamps. They can decide to tolerate slight variations. Or they
> could just look at the difference between the in and out timestamp,
> abandoning the synchronization requirement altogether (a
Good morning Joost,
> That is definitely a concern. It is up to senders how to interpret the
> received timestamps. They can decide to tolerate slight variations. Or they
> could just look at the difference between the in and out timestamp,
> abandoning the synchronization requirement
Hi ZmnSCPxj,
Before proceeding with discussing HMACs and preventing nodes from putting
> words in the mouths of other nodes, perhaps we should consider, how we can
> ensure that nodes can be forced to be accurate about what happened.
>
> For instance, a proposal is for nodes to put timestamps for
Hello list,
In Lightning, the reliability of payments is dependent on the reliability
of the chosen route. Information about previous payment attempts helps to
select better routes and improve the payment experience. Therefore
implementations usually track the past performance of nodes and
