Good morning Rusty, > > 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?
Why not the same onion-in-an-onion we use in trampoline? We could probably optimize this a little since we do not need to send data like outgoing amounts and timelocks and stuff but basically the same construction seems to work? Without the ability to send messages in the reverse direction, a failure would be silent. In particular, if I send out a direct message and then not get a response after a while, I might be tempted to send out another direct message over a different path. Then whatever was stuck gets unstuck and the recipient gets two messages (and I might get two responses back after a while). This implies that any higher-level protocol built on this must treat this like a UDP request-response: unreliable delivery, possible multiple copies of the same message getting received, probably have to send multiple copies for reliable delivery, etc. In particular, requests that change the world must be idempotent. But I suppose that also applies for your original formulation as well. > > > 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. Apparently, since nobody replied to it. > > 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. In principle any use of hashcash can be replaced with a spend of Bitcoin, hmmm. > > (Really want to use some kind of Chaumian token here, but it's probably > overkill). No, Chaumian tokens are cool, we should totally add it for nerd points. But I mean: if it works better that way, why not? Implementation complexity I suppose? waxwing showed a PoDLE-based Chaumian token protocol which, at least to my naive eyes, is not susceptible to Wagnerian attack the way blind Schnorr signatures are, so it seems to be something we can use as a way to issue tokens in a manner very much like Chaumian banks do. Though it does require getting the reciprocal of a scalar, an operation which is not exposed in secp256k1.h for some reason. https://privacypass.github.io/protocol > > > 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. .... Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
