Sampling Protocol / Fisherman is gameable

[DragonDmoney]

Problem

The Sampling Protocol of the Fisherman (according to the spec) is able to be manipulated by ServiceNodes. According to the spec, there is a Consistent Sampling Delay between every benchmark/sample of all the service nodes in a session. An attacker could monitor his incoming requests, figure out the delay, and only give service to the Fisherman instead of to all applications.

The aim of the Sampling Protocol is to be discreet, so ServiceNodes do not know which requests are from the Fisherman or an application, and they are forced to give equal service to all requests. However, this is not the case.

How to attack the current system

1. Wait till two or more of your nodes are in the same session.
2. Monitor all incoming requests and send them to a shared server
3. Identify requests that came in at the same time
4. Identify another set of requests that came in at the same time
5. Subtract and determine the consistent sampling delay
6. Ignore all other requests between now + Consistent Sampling Delay

Solution

Change the Consistent Sampling Delay to a Random Sampling Delay, created from a private source of randomness.

Origin Document

https://docs.pokt.network/v1/utility#3.3-fisherman-protocol

Creator: DragonDmoney (Pierre)

[Olshansk]

tl;dr Extremely unlikely, but I'd still be in favour of this change.

I wanted to highlight that though this attack is possible, it is very unlikely:

1. From the spec: a limited ApplicationAuthenticationToken and Ephemeral Private key is provided to Fishermen which enables them to make sampling requests to all of the ServiceNodes in the Session on the Application’s behalf. Just a reminder that requests the fisherman and the app could look the same.
2. Even when measuring RTT, the likelihood of two requests arriving at the same time, and the servicers being fully synched is highly improbable.
3. Point (2) becomes even more unlikely if the application is making many requests through a session, which makes them indistinguishable when assisted by (1).

With that being said, through the Law of large numbers, I've also been thinking that a random sampling delay makes more sense as the # of fisherman & servicers grows and we want to get an unbiased and an undetectable view of their performance.

@andrewnguyen22: do you see any reasons not to make this change?

[BenVanGithub]

Any attack who's risk adjusted outcome exceeds the expected gain or who's ultimate purpose is anything other than maximizing net gain is called a Mad Man Attack.

This particular attack is outlined in the original V1 pre-spec as: The Mad Man Blogger Attack. Although there is the potential for a minor cost savings for the attacker by reducing this total bandwidth charges (if he pays that way). The savings is very small compared to the amount of effort required to code, test and maintain this patch, and the risks associated with false-positives are expected to be quite significant. It is not possible to respond to a "doxed" fisherman faster than any other request, therefore the requisite backend and service provision must still be up and running. This attack is more of a social attack, where the goal of the attacker is to discredit the Pocket services itself.

I like the randomization idea. However IIRC, the reason that we stuck with fixed intervals for sampling was because it was extremely light-weight compared to submitting proofs which contained timestamps on each sample.

I would be in favor of this change if we can implement it without significantly bloating or slowing down the proof checking process. And I'd appreciate any thoughts or suggestions that you may have on that topic.

Personally, I'm super glad to know and see that you are reading and thinking about V1. I'm certain that we did not cover every hole and more eyes and brains on the job are very welcome.

Thank you - BenVan

[DragonDmoney]

I wouldn't classify this as a madman attack @BenVanGithub as it wouldn't be too difficult to implement, and would give a huge reward for large node providers. In theory, the majority of node runner infrastructure costs would be blockchain nodes for servicing relays, and if this attack was executed properly, a node runner could cut the majority of their blockchain nodes without losing rewards. I'm not 100% sure about this solution, but maybe the Fisherman generates a random number/entropy, and there is a deterministic function that generates timestamps from that random number, and that way, the fisherman only includes that random number in the proof instead of a bunch of timestamps, which should reduce any extra blockchain bloat a random sampling delay would create.

Another way that a malicious actor could figure out the consistent sampling delay and time sync of the Fisherman is by giving the Fisherman an ApplicationAuthenticationToken of their own, and waiting to see relays come from that application.

[BenVanGithub]

That's a cool idea!