[Lightning-dev] SURBs as a Solution for Protocol-Level Payment ACKs
rusty at rustcorp.com.au
Tue Feb 19 00:50:25 UTC 2019
Olaoluwa Osuntokun <laolu32 at 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 :)
More information about the Lightning-dev