Jim Posen [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-09 📝 Original message: Thanks for the thoughtful ...

📅 Original date posted:2018-05-09
📝 Original message:
Thanks for the thoughtful responses.

> You missed the vital detail: that you must prove channel closure if you
> can't unpeel the onion further. That *will* hit an unresponsive party
> with a penalty.

Ah, that is a good point. I still find the proposal overall worryingly
complex in terms of communication overhead, time it takes to prove channel
closure, all of your points in [1], [2], [3], etc. Furthermore, this
mandates that immediate channel closure is the only allowed reaction to a
party delaying an HTLC for a time period above a threshold -- the node
reputation approach gives more discretion to the preceding hop.
Deobfuscating the route may turn out to be the right option, but I think
the reputation system has certain advantages over this.

> The models we tried in Milan all created an incentive to fail payments,
> which is a non-starter.

Do you mind elaborating or summarizing the reasons? The way I'm analyzing
it, even if there's a nominal spam fee paid to routing nodes that fail
payments, as long as it's low enough (say 2-5% for arguments sake), the
nodes still have more to gain by forwarding the payment and earning the
full fee on a completed payment, and possibly the reputation boost
associated with completing a payment if that system was in effect.
Moreover, a node that constantly fails payments will be blacklisted by the
sender eventually and stop receiving HTLCs from them at all. Overall, I
don't think this is a profitable strategy. Furthermore, I think it works
quite well in combination with the reputation system.

> This seems like we'd need some serious evaluation to show that this
> works, because the risks are very high.

I agree that it needs to be evaluated. I may start working on some network
simulations to test various DOS mitigation strategies.

> I can destroy your node's reputation by routing crap through you; even
> if it costs me marginaly more reputation than it does you, that just
> means that the largest players can force failure upon smaller players,
> centralizing the network. And I think trying to ensure that it costs me
> more reputation than the sum of downstream reputation loss leaks too
> much information

I will add to ZmnSCPxj's response, which is mostly on point. The key here
is that the only way to lose significant reputation is to delay a payment
yourself or forward to a malicious downstream that delays -- neither of
these can be forced by the sender alone. This amounts to a system where you
are on the hook for any malicious behavior of your downstream peers, which
is why you must keep a reputation score for each which they earn over time.
This should keep all links in the network high quality and quickly
disconnect off delaying nodes if the incentives are right.

While I agree that a lot of reputation is leaked by aggregating the losses
along the route, this serves exactly to prevent large nodes with high
reputation from ruining links elsewhere. There are two things a node
looking to cause reputation loss could do. 1) Identify a node (not itself)
it thinks will delay a payment and send to them. This locks up funds on
their behalf, but is actually good behavior because it identifies a faulty
node and rightfully forces a loss in their reputation, eventually resulting
in them being booted from the network. Everyone upstream loses some
reputation for having connectivity to them, but less because of the loss
aggregation along the route. 2) Delay a payment oneself and force upstream
reputation loss. This is why I think it's important that the reputation
loss aggregate so that the malicious party loses the most.

As for the amount of information leaked, yes, it helps determine the number
of upstream hops in a route. However, the CLTV values help determine the
number of downstream hops in a route in exactly the same way. I see these
as symmetric in a sense.

To address ZmnSCPxj's point:

> But it also looks more and more like a policy of "just
`update_htlc_fail`" keeps our reputation high: indeed never accepting a
forwarding attempt would ensure reputation.
> However, earning via fees should help provide incentive against "Just
`update_htlc_fail`" always. If the goal is "how do I earn money fastest"
then there is some optimal threshhold > of risk-of-reputation-loss vs.
fee-earnings-if-I-forward that is unlikely to be near the "Just fail it"
spectrum, but somewhere in between. We hope.

This is exactly the question that your local view of peer reputations helps
solve: are the potential fees here worth the risk of forwarding this
payment to this downstream? If their reputation is high, then you will want
to forward because you think there's a low chance of you incurring
reputation loss. If their reputation is low and the HTLC value is too high,
you will fail it. So I disagree that "just `update_htlc_fail`" is an
optimal strategy. Consider as well that all fees you earn on successful
payments are profit to you as well as a reputation boost in the view of
both of your peers. So in order to earn reputation, you have to forward
payments. The key is not forwarding through malicious peers.

-jimpo

On Wed, May 9, 2018 at 12:31 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Rusty, Jim, and list,
>
> > I can destroy your node's reputation by routing crap through you; even
> >
> > if it costs me marginaly more reputation than it does you, that just
> >
> > means that the largest players can force failure upon smaller players,
> >
> > centralizing the network.
>
> My understanding of the proposal was that reputation loss would occur only
> if the reply (`update_htlc_fail` or `update_htlc_success`) is delayed; this
> means that for you to force me to lose reputation, you need to somehow make
> me delay my reply. In particular if you do simple things like give me an
> invalid onion, or make me forward to a payee who does not know the
> preimage, I do not lose reputation by replying very quickly with an
> `update_htlc_fail`.
>
> Of course, a large player could force reputation loss by delaying reply
> when they receive, and having patsy nodes route to them. So for instance
> if it is Jim -> ZmnSCPxj -> Rusty, and Rusty activates the
> Blockstream-takes-over-the-world Apocalypse program, the Rusty node would
> then delay for a long time before replying, which makes my reputation
> suffer. But it also makes Rusty reputation suffer even more and my
> reaction would be that, the next time Jim hands me an HTLC that forwards to
> Rusty, I would instead quickly `update_htlc_fail` back to Jim (which does
> not lose me significant reputation due to my quick response) than risk
> forwarding it to you, since you have a reputation for being slow and
> unresponsive.
>
> Indeed, another aspect of Jim proposal is that it is extremely local: if
> Jim has no channel to Rusty, then Jim has no opinion about Rusty, only
> about ZmnSCPxj. However, ZmnSCPxj does have an opinion about Rusty, as
> ZmnSCPxj has channel with Rusty. If I suffer too much reputation loss due
> to Rusty, my opinion of Rusty drops even faster, and I decide to
> `update_htlc_fail` in order to prevent Jim opinion of me from dropping too
> much that Jim decides not to forward to me (if I have other channels with
> more reasonable nodes).
>
> But it also looks more and more like a policy of "just `update_htlc_fail`"
> keeps our reputation high: indeed never accepting a forwarding attempt
> would ensure reputation.
>
> However, earning via fees should help provide incentive against "Just
> `update_htlc_fail`" always. If the goal is "how do I earn money fastest"
> then there is some optimal threshhold of risk-of-reputation-loss vs.
> fee-earnings-if-I-forward that is unlikely to be near the "Just fail it"
> spectrum, but somewhere in between. We hope.
>
> > And I think trying to ensure that it costs me
> >
> > more reputation than the sum of downstream reputation loss leaks too
> >
> > much information
>
> Yes, this is a major drawback of the proposal. The rate at which the
> sender of the HTLC threatens me with reputation loss lets me estimate my
> distance from the ultimate sender of the funds.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180509/1cec1f17/attachment-0001.html>;