Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-03 🗒️ Summary of this message: A continuous ...
📅 Original date posted:2023-03-03
🗒️ Summary of this message: A continuous solution can differentiate between an active attacker and a low-traffic neighbor, unlike a binary solution that blocks all low-reputation nodes. Reporting c truthfully is crucial to avoid reputation penalties.
📝 Original message:
> With a binary solution a single attacker can easily fill your quota of
> low-confidence HTLCs and then all low-reputation nodes are blocked. But not
> all of them are attackers, some of them just don't send you enough traffic
> to get a high reputation for instance and you're going to block them too.
> With a continuous solution you can differentiate between an active attacker
> and someone who just sends to nodes with poor connectivity and only block
> the first.
>
If it's very cheap to behave like a neighbour with poor connectivity, why
wouldn't the attacker mimic this, and then block?
Differentiating between a potential attacker and just a low-traffic
neighbour is very difficult. I think that instead of "low/high reputation"
a better way to think about it is "unknown/endorsed", and just consider
which neighbour needs access to all resources and which one doesn't.
The idea of different bins was brought up a few times and might help a bit,
but I am not sure at all that it is worth the complication.
For reporting c truthfully, if you report it too high you will be penalized
> by having your reputation lowered, if you report it too low you will
> penalize your HTLCs and still get the same reputation as if you had
> reported it truthfully.
>
It might be that there is a strong motivation to underestimate than
overestimate. That is – the punishment for underestimating by X is
significantly smaller than for overestimating by X (or vice versa). The
formula you choose can affect this significantly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/4c8fa6ae/attachment.html>;
🗒️ Summary of this message: A continuous solution can differentiate between an active attacker and a low-traffic neighbor, unlike a binary solution that blocks all low-reputation nodes. Reporting c truthfully is crucial to avoid reputation penalties.
📝 Original message:
> With a binary solution a single attacker can easily fill your quota of
> low-confidence HTLCs and then all low-reputation nodes are blocked. But not
> all of them are attackers, some of them just don't send you enough traffic
> to get a high reputation for instance and you're going to block them too.
> With a continuous solution you can differentiate between an active attacker
> and someone who just sends to nodes with poor connectivity and only block
> the first.
>
If it's very cheap to behave like a neighbour with poor connectivity, why
wouldn't the attacker mimic this, and then block?
Differentiating between a potential attacker and just a low-traffic
neighbour is very difficult. I think that instead of "low/high reputation"
a better way to think about it is "unknown/endorsed", and just consider
which neighbour needs access to all resources and which one doesn't.
The idea of different bins was brought up a few times and might help a bit,
but I am not sure at all that it is worth the complication.
For reporting c truthfully, if you report it too high you will be penalized
> by having your reputation lowered, if you report it too low you will
> penalize your HTLCs and still get the same reputation as if you had
> reported it truthfully.
>
It might be that there is a strong motivation to underestimate than
overestimate. That is – the punishment for underestimating by X is
significantly smaller than for overestimating by X (or vice versa). The
formula you choose can affect this significantly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230303/4c8fa6ae/attachment.html>;