[Lightning-dev] SURBs as a Solution for Protocol-Level Payment ACKs

Rusty Russell 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 mailing list