Olaoluwa Osuntokun <laol...@gmail.com> writes: > Hi y'all, > > Recently we've started to do more design work related to the Sphinx packet > (EOB format, rendezvous protocol). This prompted me to re-visit the original > Sphinx paper to refresh my memory w.r.t some of the finer details of the > protocol. While I was re-reading the paper, I realized that we may be able > to use use SURBs (single-use-reply-blocks) to implement a "payment ACK" for > each sent HTLC. > > (it's worth mentioning that switching to HORNET down the line would solve > this problem as well since the receiver already gets a multi-use backwards > route that they can use to send information back to the receiver)
I think HORNET is a better way forward for soft errors, since using the same circuit is *way* more reliable (Christian indicated most probe failures are due to disconnected nodes, not capacity). I'd like to see us work towards that instead, at least in baby steps. > Right now HTLC routing is mainly a game of "send and hope it arrives", as > you have no clear indication of the _arrival_ of an HTLC at the destination. > Instead, you only receive a protocol level message if the HTLC failed for > w/e reason, or if it was successfully redeemed. As part of BOLT 1.1, it was > agreed upon that we should implement some sort of "payment ACK" feature. A > payment ACK scheme is strongly desired as it: > > * Allows the sender to actually know when a payment has reached the > receiver which is useful for many higher level protocols. Atm, the > sender is unable to distinguish an HTLC being "black holed" from one > that's actually reached the sender, and they're just holding on to it. Agreed, though in the long run we'll have to do something about that. > * AMP implementations would be aided by being able to receive feedback on > successfully routed splits. If we're able to have the receiver ACK each > partial payment, then implementations can more aggressively split > payments as they're able to gain assurance that the first 2 BTC of 5 > total have actually reached the sender, and weren't black holed. Yes, I suspect this will quickly get messy. Sender wants longer timeouts for AMP, network definitely doesn't. In my current draft I chose 60 seconds for the timeout, but that's a compromise. > * Enforcing and relying on ACKs may also thwart silly games receivers > might play, claiming that the HTLC "didn't actually arrive". And general debugging and diag as the network gets larger. > Some also call this feature a "soft error" as a possible implementation > might to re-use the existing onion error protocol we've deployed today. For > reference, in order to send back errors back long the route in a way that > doesn't reveal the sender of the HTLC to the receiver (or any of the > intermediate nodes) we re-use the shared secret each hop has derived, and > onion wrap a MAC'd error to the sender. Each hop can't actually check that > they've received a well formed error, but the sender is able to attribute an > error to a node in the route based on which shared secret they're able to > check the MAC with. Either way, someone should spec that :) Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
