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

[ZmnSCPxj]

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