From ZmnSCPxj at protonmail.com Fri Oct 15 14:29:15 2021 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 15 Oct 2021 14:29:15 +0000 Subject: [Lightning-dev] In-protocol liquidity probing and channel jamming mitigation In-Reply-To: <20211015135529.GA23013@jauntyelephant.191.37.198.vultr.com> References: <20211015135529.GA23013@jauntyelephant.191.37.198.vultr.com> Message-ID: 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