Hi all, 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 <hiroki.go...@nayuta.co>: > 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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
