ZmnSCPxj <zmnsc...@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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
