[Lightning-dev] In-protocol liquidity probing and channel jamming mitigation

[ZmnSCPxj]

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