Hi ZmnSCPxj and Bastien, When I was putting together this proposal, I thought it would be difficult for me to consider all the security and privacy issues. I am very glad that you raised the possible issues.
> So my opinion, it is best to retain this property of "D does not know payer A". I agree with your opinion too. I thought there was no problem if the ACK and the PoP were responses of the HTLCs and the key respectively. But, > The added communication round may allow intermediate node to guess the payer. > With addition of new ACK-key turnaround, intermediate node can measure time from send of ACK to receive of key, and guess its distance to payer. Right. > A can select another route (e.g. D -> E -> F -> A) and can create the ACK > onion packet during the setup phase. > A can then embed this ACK packet inside the last hop payload of the > *add_htlc* onion packet. > When D receives it, it simply sends that onion to the indicated recipient > (E) which will unwrap and forward. > This way D doesn't learn anything about A, and intermediate nodes aren't > included in the ACK route so > they don't learn anything either. I think this is likely to be an improvement. This could also be generalized as a case where a packet we send goes back to us via a given node. I need to understand more precisely the limitations of the onion packet including new specs under development. In the process, I will also consider combination of this proposal with AMP and new routing algorithms (Trampoline, Rendezvous). Regards, Hiroki
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
