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 <[email protected]>: > > > 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
