Good morning Owen,

> On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
>
> > So how would things work out with a combination of both of the
> > proposals described in this mail? First we make probing free (free as
> > in no liquidity locked up) and then we'll require senders to pay for
> > failed payment attempts too. Failed payment attempts after a
> > successful probe should be extremely rate, so doesn't this fix the ux
> > issue with upfront fees?
>
> Why couldn't a malicious routing node (or group of colluding routing
> nodes) succeed the probe and then fail the payment in order to collect
> the failed payment fee?

Good observation!

I propose substantially the same thing here: 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html

In that proposal, I wrote:

> Another thought is: Does the forwarding node have an incentive to lie?
> Suppose the next hop is alive but the forwarding node has insufficient 
> capacity towards the next hop.
> Then the forwarding node can lie and claim it can still resolve the HTLC, in 
> the hope that a few milliseconds later, when the actual HTLC arrives, the 
> capacity towards the next hop has changed.
> Thus, even if the capacity now is insufficient, the forwarding node has an 
> incentive to lie and claim sufficient capacity.
>
> Against the above, we can mitigate this by accepting "no" from *any* node 
> along the path, but only accepting "yes" from the actual payee.

We already have a mechanism to send an onion and get back an "error" reply; the 
reply can be identified by the sender as arising from any node along the path, 
or at the destination.
Basically, we simply reuse this mechanism:

* Do not need an HTLC with this onion.
* Only accept a "everything is OK" result from the destination.
* Accept a "sorry cannot forward" from *any* node along the path.

Thus, a malicious node cannot succeed the probe --- the probe has to reach the 
destination.

Now the malicious forwarding node could be colluding with the destination, but 
presumably the destination wants to *actually* get paid, so we expect that, 
economically, it has no incentive to cooperate with the malicious node to 
*fail* the actual payment later just to extract a tiny failure fee.

Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to