From hiroki.gondo at nayuta.co Thu Jun 27 09:45:13 2019 From: hiroki.gondo at nayuta.co (Hiroki Gondo) Date: Thu, 27 Jun 2019 18:45:13 +0900 Subject: [Lightning-dev] Proposal for Stuckless Payment In-Reply-To: References: <8s41n9adqo2-xQ-BnFuqyO5_X_iw7dFAvDLrz3v3hM14-4LMPWejtzA-TpkbXCv1EuOESulAep1boIqJD9iyiPYbjr3UU5OXaR8Xfoh3nnc=@protonmail.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: