Author: Rusty Russell 2020-02-21 00:03:33
Published on: 2020-02-21T00:03:33+00:00
ZmnSCPxj is concerned that in a conversation where multiple requests and responses are exchanged between two parties, the timing of the messages can provide hints to an intermediate node about the distance between the two parties. To avoid this, ZmnSCPxj suggests creating a circular path instead of using the same path each time. This would eliminate timing attacks as Alice and Bob could be anywhere along the circle. It would also eliminate storage requirements for intermediaries. The lack of "reply" function currently makes it impossible to fit the reply onion inside the existing onion, but Christian has a solution for it. Rusty notes that this approach is ideal for "offers" which cause an invoice request, followed by an invoice reply. However, its usefulness may not justify setting up a circuit for just two uses. Rusty mentions having tied this to an HTLC in an attempt to provide a spam-limit, but was not successful. He proposes some hashcash scheme combined with the ability to buy a single-use token to weaken it to prevent information leaks. ZmnSCPxj asks how this approach compares to requiring all Lightning nodes to have a Tor .onion address and just doing direct messaging over Tor. Rusty acknowledges that using Tor would be far better, but it's not happening. Lnurl over https is happening, so using lightning to tunnel messages is a strict improvement over that.
Updated on: 2023-06-02T23:46:17.831575+00:00