Jim Posen [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-09 📝 Original message: One more point in terms ...
📅 Original date posted:2018-05-09
📝 Original message:
One more point in terms of information leakage is that noise can be added
to the "this is the rate that you'll lose reputation at" field to help
obfuscate the number of upstream hops. I proposed setting it to "this is
the upstream rate that I'm losing reputation at" + downstream HTLC value,
but a node can decide to add noise. If they make it too low however,
there's a risk of insufficiently punishing bad nodes and if they make it
too high, there's a heightened risk that the payment fails because the
downstream reputation is insufficient along the route.
This is why I say it's kind of symmetric to the CLTV value: if the delta is
too low, there's risk of loss of funds, if the delta is too high, someone
might decide to fail the payment instead of taking the delay risk.
On Wed, May 9, 2018 at 10:23 AM, Jim Posen <jim.posen at gmail.com> wrote:
> 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/1894d9e0/attachment-0001.html>;
📝 Original message:
One more point in terms of information leakage is that noise can be added
to the "this is the rate that you'll lose reputation at" field to help
obfuscate the number of upstream hops. I proposed setting it to "this is
the upstream rate that I'm losing reputation at" + downstream HTLC value,
but a node can decide to add noise. If they make it too low however,
there's a risk of insufficiently punishing bad nodes and if they make it
too high, there's a heightened risk that the payment fails because the
downstream reputation is insufficient along the route.
This is why I say it's kind of symmetric to the CLTV value: if the delta is
too low, there's risk of loss of funds, if the delta is too high, someone
might decide to fail the payment instead of taking the delay risk.
On Wed, May 9, 2018 at 10:23 AM, Jim Posen <jim.posen at gmail.com> wrote:
> 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/1894d9e0/attachment-0001.html>;