Owen Gunden [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-15 📝 Original message: On Fri, Oct 15, 2021 at ...
📅 Original date posted:2021-10-15
📝 Original message:
On Fri, Oct 15, 2021 at 02:29:15PM +0000, ZmnSCPxj wrote:
> 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.
Under Joost's proposal, there's even more of an incentive to lie: sats
to be had.
> > Against the above, we can mitigate this by accepting "no" from *any*
> > node along the path, but only accepting "yes" from the actual payee.
This doesn't really help if all the routers along the way are lying and
saying 'yes'. Only the payee's 'yes' is meaningful, and she doesn't have
enough information to know if the routers were lying or not.
I think the actual enforcement mechanism is (also from your proposal
Zmn):
> > Presumably, when a node receives a question, it checks if the asking
> > node has sufficient capacity towards it first, and if not, fails the
> > channel between them, since obviously the asking node is not
> > behaving according to protocol and is buggy.
But I'm not sure the incentives align for this tattling on your neighbor.
Let's take an example A -> B -> C -> D
A sends a probe towards D. B doesn't have sufficient liquidity to send
to C. But B is a liar. B says 'yes'.
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)."
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.
Maybe Joost's suggestion of using a simple reputation scheme would work.
📝 Original message:
On Fri, Oct 15, 2021 at 02:29:15PM +0000, ZmnSCPxj wrote:
> 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.
Under Joost's proposal, there's even more of an incentive to lie: sats
to be had.
> > Against the above, we can mitigate this by accepting "no" from *any*
> > node along the path, but only accepting "yes" from the actual payee.
This doesn't really help if all the routers along the way are lying and
saying 'yes'. Only the payee's 'yes' is meaningful, and she doesn't have
enough information to know if the routers were lying or not.
I think the actual enforcement mechanism is (also from your proposal
Zmn):
> > Presumably, when a node receives a question, it checks if the asking
> > node has sufficient capacity towards it first, and if not, fails the
> > channel between them, since obviously the asking node is not
> > behaving according to protocol and is buggy.
But I'm not sure the incentives align for this tattling on your neighbor.
Let's take an example A -> B -> C -> D
A sends a probe towards D. B doesn't have sufficient liquidity to send
to C. But B is a liar. B says 'yes'.
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)."
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.
Maybe Joost's suggestion of using a simple reputation scheme would work.