From rusty at rustcorp.com.au Fri Feb 21 00:03:33 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 21 Feb 2020 10:33:33 +1030 Subject: [Lightning-dev] Direct Message draft In-Reply-To: References: <87eeupmwg8.fsf@rustcorp.com.au> Message-ID: <87lfowlsbu.fsf@rustcorp.com.au> ZmnSCPxj 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.