[Lightning-dev] Proposal for Stuckless Payment

[Bastien TEINTURIER]

This is a very good proposal, thanks Hiroki for all those details it helped
me learn a lot.

If I'm not mistaken, https://eprint.iacr.org/2018/472.pdf has shown that we
MUST add another round
of communication if we want to avoid the wormhole attacks (and thus
decorrelate payments). While
I agree that this degrades latency, if it provides a way to "cancel" stuck
payments and retry I think it's
worth it. And I really like the option to make multiple tries in parallel
as you suggest, which would help
with latency (if you have enough outbound capacity).

I agree with ZmnSCPxj that it would be good to keep payer anonymity, and I
may have a solution to
provide this. As ZmnSCPxj explains, the loss of payer anonymity is due to
the ACK message traveling
via the same route (D -> C -> B -> A).

However, there are two interesting things to note about the ACK message
(unless I missed something):

   1. It doesn't need any data from D
   2. It isn't tied to channels and only A needs to receive it (not
   intermediate nodes)
   3. It could use a smaller onion packet than the *add_htlc* onion (fixed
   size but smaller than 1300 bytes)

Given 1., the ACK onion packet can be constructed by A. Given 2., it can
use a different route than the
*add_htlc* onion packet.

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.

Note that nodes in the ACK message route don't have an incentive to forward
ACK messages (apart from
participating honestly in the network). But even if a malicious node drops
an ACK message, it just ends up
being a stuck payment that you can safely retry since you haven't shared
the keys yet.

And if A doesn't care about anonymity at all, A can provide its information
in the onion to let D directly send it
the ACK. I don't know if we want to provide that option or not, but at
least that's possible to do.

Would that be a satisfactory solution to maintain the payer anonymity
property?

Cheers,
Bastien

Le mar. 25 juin 2019 à 12:16, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

> Good morning Hiroki,
>
> Thank you for this.
> It seems a good solution.
> And, it seems, yet another reason to move to payment point / scalar from
> payment hash / preimage.
>
> As I understand it, the `y0+y1+...` sums are also the blinding tweaks used
> for payment decorrelation.
> My understanding, they will be sent in onion packet.
>
> > Pre-Settlement: Add this new phase after the Update phase. Any route can
> be used.
> >
> >         A --> * --> * --> D        # key (`y0+y1+y2`)
> >
> >         A <-- * <-- * <-- D        # PoP (`z`)
>
> My poor suggestion, to use same route ->B->C-> and <-B<-C<-.
> Currently, destination D does not know who is payer A.
> So my opinion, it is best to retain this property of "D does not know
> payer A".
>
> Of course, in practice in many case, D knows A already, for example for
> delivery address of product.
> But anonymity should be preserved still.
> For example, perhaps I wish to deliver product to some other entity other
> than me, and wish to remain anonymous to do so.
>
> However, I seem, the detail below, means we should use the same route:
>
> > At the end of this phase, we require the payee return the ACK to the
> payer to notify the completion of this phase. It must be guaranteed that
> the payee himself returns it. This can be achieved by reversing the route
> and wrapping the ACK in the onion sequentially, as the `reason` field of
> the `update_fail_htlc` in BOLT 1.x.
>
>
>
> > These modifications add the cost of three new messages (ACK, key, PoP),
> but it is only three (unaccompanied by other messages). These may also
> reduce other preventive messages.
>
> The added communication round may allow intermediate node to guess the
> payer.
>
> Already in current network, intermediate node can guess the distance to
> payee.
> Distance to payee can be guessed from timelocks.
> Also, distance to payee can be guessed by time from `update_add_htlc` to
> time of `update_fulfill_htlc`/`update_fail_htlc`.
>
> However, there is no information that intermediate node can use to guess
> distance to 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.
>
> I am uncertain how to weigh this.
> I believe, this idea is very good and stuckless is important feature.
> Getting some information about the payer may allow attempts at censorship,
> however.
> But maybe the information leaked is not significant enough in practice.
>
> Another issue is the added latency of payments.
> Already, because of cooperative signing by use of MuSig, we know that
> latency of payment point / scalar is worsened.
> But use of ACK-key turnaround increases latency further.
> Of course, we should consider, most of latency is because of retries.
> With "stuckless" payment, we can (if we have enough money) make multiple
> tries in parallel.
> So possibly, this may reduce latency "in the large" at the cost of
> increasing latency "in the small".
>
> Another thought, is that this may also solve the "American Call Option"
> problem.
> In this case, the key at the final step is the sum of the payer key and
> the exchange key (`y0 + y1 + y2 + z` where payer knows `y0 + y1 + y2` and
> exchange knows `z`).
> Then intermediate nodes are unaware that a cross-currency exchange is
> involved.
> This thought, I will need to consider further for correctness.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190625/28d783f9/attachment.html>