Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-14 📝 Original message: Hi ZmnSCPxj, Before ...
📅 Original date posted:2019-06-14
📝 Original message:
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 certain events.
> Does this imply that all nodes along the route **MUST** have their clocks
> strongly synchronized to some global clock?
> If a node along the route happens to be 15 seconds early or 15 seconds
> late, can it be erroneously "dinged" for this when a later hop delays a
> successful payment for 20 seconds?
>
> If it requires that hop nodes have strong synchrony with some global clock
> service, why would I want to run a hop node then?
> What happens if some global clock service is attacked in order to convince
> nodes to route to particular nodes (using a competing global clock service)
> on the Lightning network?
>
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 node could also
just report that difference instead of two timestamps). The held duration
is enough to identify a pair of nodes from which one of the nodes is
responsible for the delay.
Example (held durations between parenthesis):
A (15 secs) -> B (14 secs) -> C (3 secs) -> D (2 secs)
In this case either B or C is delaying the payment. We'd penalize the
channel between B and C.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190614/4b3f5654/attachment.html>;
📝 Original message:
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 certain events.
> Does this imply that all nodes along the route **MUST** have their clocks
> strongly synchronized to some global clock?
> If a node along the route happens to be 15 seconds early or 15 seconds
> late, can it be erroneously "dinged" for this when a later hop delays a
> successful payment for 20 seconds?
>
> If it requires that hop nodes have strong synchrony with some global clock
> service, why would I want to run a hop node then?
> What happens if some global clock service is attacked in order to convince
> nodes to route to particular nodes (using a competing global clock service)
> on the Lightning network?
>
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 node could also
just report that difference instead of two timestamps). The held duration
is enough to identify a pair of nodes from which one of the nodes is
responsible for the delay.
Example (held durations between parenthesis):
A (15 secs) -> B (14 secs) -> C (3 secs) -> D (2 secs)
In this case either B or C is delaying the payment. We'd penalize the
channel between B and C.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190614/4b3f5654/attachment.html>;