Christian Decker <decker.christ...@gmail.com> writes: > Rusty Russell <ru...@rustcorp.com.au> writes: > >> 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? > > I think circular payment really means an onion that is > >> A -> ... -> B -> ... -> A > > and not a reply onion inside of a forward onion. > > The problem with the circular path is that the "recipient" cannot add > any reply without invalidating the HMACs on the return leg of the > onion. The onion is fully predetermined by the sender, any malleability > introduced in order to allow the recipient to reply poses a threat to > the integrity of the onion routing, e.g., it opens us up to probing by > fiddling with parts of the onion until the attacker identifies the > location the recipient is supposed to put his reply into. > > As Rusty mentioned I have a construction of the onion routing packet > that allows us to compress it in such a way that it fits inside of the > payload itself.
I think this has the same problem though, that there's no way Alice can send Bob an onion to use with an arbitrary message? > Another advantage is that the end-to-end payload is not covered by the > HMACs in the header, meaning that the recipient can construct a reply > without having to modify (and invalidate) the routing onion. I guess > this is going back to the roots of the Sphinx paper :-) Good point, and it's trivial. The paper suggests the payload be "final key" followed by the desired data, providing a simple validation scheme. We could potentially generalize the HTLC messages like this, but it's unnecessary at this point. Thanks, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
