Application score parameter leaves an implementation weakness

[dylanlott]

The application score parameter is ambiguous enough that client implementations could be susceptible to exploits through gaming differences between implementations and their specific handling of the application score. It's given a positive weight but the value of the actual score itself is left up to the application.

[dylanlott]

The application score is weighted positively but the value of it is left up to the client implementation. This creates a disparity in scoring between different implementations that the specification can’t reason about or protect against. For example, the Filecoin Lotus implementation has application score controls that protect against Sybil attacks via peer exchange by raising the score floor above what a node can achieve in normal gossip behavior, but this detail could be lost in other implementations

[vyzo]

Well, this detail is actually documented in the spec, perhaps not so clearly though. What do you suggest we should do about it?

[vyzo]

We also have a section in the spec that has not been written yet, titled "Guidelines for Tuning the Scoring Function". I think we can incorporate recommendations and remove the ambiguity there.

[dylanlott]

You're referring to this passage, yes? acceptPXThreshold: when a peer sends us PX information with a prune, we only accept it and connect to the supplied peers if the originating peer's score exceeds this threshold. This threshold should be non-negative and for increased security a large positive score attainable only by bootstrappers and other trusted well-connected peers.

[vyzo]

Yes.