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

[Joost Jager]

There could be some corners where the incentives may not work out 100%, but
I doubt that any routing node would bother exploiting this. Especially
because there could always be that reputation scheme at the sender side
which may cost the routing node a lot more in lost routing fees than the
marginal gain from the upfront payment.

Another option is that nodes that don't care to be secretive about their
channel balances could include the actual balance in a probe failed
message. Related: https://github.com/lightningnetwork/lightning-rfc/pull/695

Overall it seems that htlc-less probes are an improvement to what we
currently have. Immediate advantages include a reduction of the load on
nodes by cutting out the channel update machinery, better ux (faster
probes) and no locked up liquidity. On the longer term it opens up the
option to charge for failed payments so that we finally have an answer to
channel jamming.

ZmnSCPxj, as first person to propose the idea (I think?), would you be
interested in opening a draft PR on the spec repository that outlines the
new message(s) that we'd need and continue detailing from there?

Joost

On Sat, Oct 16, 2021 at 12:51 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Owen,
>
> > C now notes that B is lying, but is faced with the dilemma:
> >
> > "I could either say 'no' because I can plainly see that B is lying, or
> > I could say 'yes' and get some free sats from the failed payment (or
> > via the hope of a successful payment from a capacity increase in the
> > intervening milliseconds)."
>
> Note that if B cannot forward an HTLC to C later, then C cannot have a
> failed payment and thus cannot earn any money from the upfront payment
> scheme; thus, at least that part of the incentive is impossible.
>
> On the other hand, there is still a positive incentive for continuing the
> lie --- later, maybe the capacity becomes OK and C could earn both the
> upfront fee and the success fee.
>
> > So C decides it's in his interest to keep the lie going. D, the payee,
> > can't tell that it's a lie when it reaches her.
> >
> > If C did want to tattle, it's important that he be able to do so in a
> > way that blames B instead of himself, otherwise payers will assume
> > (incorrectly, and to C's detriment) that the liquidity deficit is with C
> > rather than B.
>
> That is certainly quite possible to do.
>
> 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/20211019/dd316d31/attachment.html>