Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: ZmnSCPxj <ZmnSCPxj at ...

📅 Original date posted:2020-02-20
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
> A concern I have brought up in the past is that if this is more than just a single request-response, i.e. if this is a conversation where Alice sends to Bob, Bob sends back to Alice, Alice sends back to Bob, and so on, then if the same path is used each time Alice sends to Bob, the timing from Bob response to Alice to the next Alice sends to Bob can help an intermediate node guess how far away Alice is from itself.
> Obviously the timing from Alice sending to Bob and Bob replying gives a hint as well as to the distance the intermediate node is to Bob already.
>
> It may be good to at least recommend that direct messages use different paths if they are part of a larger conversation between the two parties.

This already applies to HTLCs, no?

> Would it not be better to create a circular path?
> By this I mean, Alice constructs an onion that overall creates a path from herself to Bob and back, ensuring different nodes on the forward and return directions.
> The onion hop at Bob reveals that Bob is the chosen conversation partner, and Bob forwards its reply via the onion return path (that Alice prepared herself to get back to her via another path).

I like it! The lack of "reply" function eliminates all storage
requirements for the intermediaries. Unfortunately it's not currently
possible to fit the reply onion inside the existing onion, but I know
Christian has a rabbit in his hat for this?

> After Alice receives the first message from Bob the circular "circuit" is established and they can continue to communicate using the same circuit: timing attacks are now "impossible" since Alice and Bob can be anywhere along the circle, even if two of the nodes in the circuit are surveillors cooperating with each other, the timing information they get is the distance between the surveillor nodes.
>
> Of course, if a node in the circular path drops the circuit is disrupted, so any higher-level protocols on top of that should probably be willing to resume the conversation on another circular circuit.

My immediate purpose for this is for "offers" which cause a invoice
request, followed by an invoice reply. This will probably be reused
once for the payment itself. 2 uses is not sufficient to justify
setting up a circuit, AFAICT.

> I believe I even tied this to an HTLC in an attempt to provide a
> spam-limit as well:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html

This part was deeply unclear. Eventually we will have to charge
up-front for forwarding HTLCs (say 5% of existing fee, plus 1msat), and
then we could use the same scheme with lesser amounts (say, 1msat) for
forwarding messages.

But I have been unable to come up with an upfront scheme which doesn't
leak information badly.

The best I can do is some hashcash scheme, combined with the ability to
buy a single-use token to weaken it. Under load, a node would raise
their hashcash difficulty, and you could either find another route,
grind your onion more to meet it, or send a payment for a token from
that node which would let your HTLC through: the preimage could even be
the XOR of some secret you send with the HTLC, and a shachain key which
gives you 1000 tokens, and you can use them in order, etc.

(Really want to use some kind of Chaumian token here, but it's probably
overkill).

> Finally: what does this improve over, say, requiring that all
> Lightning nodes have a Tor .onion address and just doing direct
> messaging over Tor?

That would be far better! But that's not happening: lnurl over https is
happening. Using lightning to tunnel messages is a strict improvement
over that, at least.

Cheers!
Rusty.