From ZmnSCPxj at protonmail.com Wed Sep 18 10:30:57 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 18 Sep 2019 10:30:57 +0000 Subject: [Lightning-dev] Proposal for Stuckless Payment In-Reply-To: References: <8s41n9adqo2-xQ-BnFuqyO5_X_iw7dFAvDLrz3v3hM14-4LMPWejtzA-TpkbXCv1EuOESulAep1boIqJD9iyiPYbjr3UU5OXaR8Xfoh3nnc=@protonmail.com> Message-ID: Ohayou Hiroki-san, I agree this possibility. Of note is that this also helps support: 1. Cross-currency swaps without premium-free American Call Option. Exchanges will demand for a premium to be paid for revelation of the second preimage. 2. Non-custodial Escrow. The second preimage is shared between the escrow and the payer. Both will also just as well be served by using points. Regards, ZmnSCPxj > > I explained Stuckless Payments on the basis of PTLCs before and some people understood that this is a proposal that can be accomplished after PTLCs are introduced. But this can also be accomplished using HTLC variants that are not compatible with BOLT 1.x HTLCs. For simplicity, I'd like to describe them in Miniscript policies (http://bitcoin.sipa.be/miniscript/). > > # The BOLT #3 offered HTLC policy > or(pk(key_revocation),and(pk(key_remote),or(pk(key_local),hash160(H)))) > -> > or(pk(key_revocation),and(pk(key_remote),or(pk(key_local),and(hash160(H),hash160(H))))) > > # The BOLT #3 received HTLC policy > or(pk(key_revocation),and(pk(key_remote),or(and(pk(key_local),hash160(H)),older(1008)))) > -> > or(pk(key_revocation),and(pk(key_remote),or(and(pk(key_local),and(hash160(H),hash160(H))),older(1008)))) > > In both cases, I just changed `hash160(H)` to `and(hash160(H), hash160(H))`. The notation seems to refer to the same `H`, but these are different. One is provided by payer and the other is provided by payee. So we don't necessarily have to wait for PTLCs. > > Regards, > Hiroki > > 2019?6?27?(?) 18:45 Hiroki Gondo : > > > 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