From ZmnSCPxj at protonmail.com Tue Jun 25 10:15:29 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 25 Jun 2019 10:15:29 +0000 Subject: [Lightning-dev] Proposal for Stuckless Payment In-Reply-To: References: Message-ID: <8s41n9adqo2-xQ-BnFuqyO5_X_iw7dFAvDLrz3v3hM14-4LMPWejtzA-TpkbXCv1EuOESulAep1boIqJD9iyiPYbjr3UU5OXaR8Xfoh3nnc=@protonmail.com> Good morning Hiroki, Thank you for this. It seems a good solution. And, it seems, yet another reason to move to payment point / scalar from payment hash / preimage. As I understand it, the `y0+y1+...` sums are also the blinding tweaks used for payment decorrelation. My understanding, they will be sent in onion packet. > Pre-Settlement: Add this new phase after the Update phase. Any route can be used. > > ????????A --> * --> * --> D? ? ? ? # key (`y0+y1+y2`) > > ????????A <-- * <-- * <-- D? ? ? ? # PoP (`z`) My poor suggestion, to use same route ->B->C-> and <-B<-C<-. Currently, destination D does not know who is payer A. So my opinion, it is best to retain this property of "D does not know payer A". Of course, in practice in many case, D knows A already, for example for delivery address of product. But anonymity should be preserved still. For example, perhaps I wish to deliver product to some other entity other than me, and wish to remain anonymous to do so. However, I seem, the detail below, means we should use the same route: > At the end of this phase, we require the payee return the ACK to the payer to notify the completion of this phase. It must be guaranteed that the payee himself returns it. This can be achieved by reversing the route and wrapping the ACK in the onion sequentially, as the `reason` field of the `update_fail_htlc` in BOLT 1.x. > These modifications add the cost of three new messages (ACK, key, PoP), but it is only three (unaccompanied by other messages). These may also reduce other preventive messages. The added communication round may allow intermediate node to guess the payer. Already in current network, intermediate node can guess the distance to payee. Distance to payee can be guessed from timelocks. Also, distance to payee can be guessed by time from `update_add_htlc` to time of `update_fulfill_htlc`/`update_fail_htlc`. However, there is no information that intermediate node can use to guess distance to 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. I am uncertain how to weigh this. I believe, this idea is very good and stuckless is important feature. Getting some information about the payer may allow attempts at censorship, however. But maybe the information leaked is not significant enough in practice. Another issue is the added latency of payments. Already, because of cooperative signing by use of MuSig, we know that latency of payment point / scalar is worsened. But use of ACK-key turnaround increases latency further. Of course, we should consider, most of latency is because of retries. With "stuckless" payment, we can (if we have enough money) make multiple tries in parallel. So possibly, this may reduce latency "in the large" at the cost of increasing latency "in the small". Another thought, is that this may also solve the "American Call Option" problem. In this case, the key at the final step is the sum of the payer key and the exchange key (`y0 + y1 + y2 + z` where payer knows `y0 + y1 + y2` and exchange knows `z`). Then intermediate nodes are unaware that a cross-currency exchange is involved. This thought, I will need to consider further for correctness. Regards, ZmnSCPxj