ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-10 📝 Original message: Good morning Jim, > One ...
📅 Original date posted:2018-05-10
📝 Original message:
Good morning Jim,
> 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.
I was about to propose this.
Indeed, I intend to implement CLTV-delay randomization for payments in C-lightning, i.e. "shadow routes", since that is a way to obfuscate the intermediate node distance from the payee. Randomizing the reputation-loss-rate is similar.
The concern however is that the CLTV already partly leaks the distance from the payee, whereas the reputation-loss-rate leaks distance from the payer. It is often not interesting to know that some entity is getting paid, but it probably far more interesting to know WHO paid WHO, so leaking both distances simultaneously is more than twice as worse as leaking just one distance.
Regards,
ZmnSCPxj
> 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/20180510/a41b665e/attachment-0001.html>;
📝 Original message:
Good morning Jim,
> 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.
I was about to propose this.
Indeed, I intend to implement CLTV-delay randomization for payments in C-lightning, i.e. "shadow routes", since that is a way to obfuscate the intermediate node distance from the payee. Randomizing the reputation-loss-rate is similar.
The concern however is that the CLTV already partly leaks the distance from the payee, whereas the reputation-loss-rate leaks distance from the payer. It is often not interesting to know that some entity is getting paid, but it probably far more interesting to know WHO paid WHO, so leaking both distances simultaneously is more than twice as worse as leaking just one distance.
Regards,
ZmnSCPxj
> 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/20180510/a41b665e/attachment-0001.html>;