Updating Farmer Directory

[littleskunk]

I see some problems here:

To discourage a bridge from being Sybil attacked, any new contacts will be given a proof-of-work challenge to add their contact.

= One time PoW

The farmer will then send an HTTP POST request to a bridge at /contacts with the headers: And with the JSON body:

= The farmer has to repeat the PoW every time he changes his IP or Port.

1.) Farmer with a dynamic IP have to do that once per day and per bridge. 2.) Farmer are technically offline while they try to update the contact information.

The timestamp is within an error threshold

3.) By using my GPU I can outperform all other farmer. I will run PoW 24/7. As reaction the bridge will increase the difficulty. Even fast CPUs will get a problem to complete PoW in time. Keep the difficulty high for 24 hours and Problem 1 and 2 will shut down farmer one by one. My own farmer (static ip and port) would love to get all the new created mirrors.

The challenge and nonce meets the expected target difficulty

4.) One validation is missing. At the moment I can register as many farmer as I want with the same PoW result. There is no validation that the challenge and nonce was used befor.

challenge + nonce

5.) It has to be nonce + challenge or I could solve PoW faster than any other farmer. There are methodes to generate the challenge hash only once and update it with the noce very fast in a loop. I can not do that for noce + challenge because it works only in one direction. Generate the nonce hash and update it with the same challenge all the time is as slow as hashing both together.

While responseTime is a pretty decent reputation metric, as discussed above

6.) ResponseTime is not usefull and never was. It includes the time for different client side validations. Do I have the shard? Is the renter allowed to request a download token? In order to get a better reputation / responseTime I would have to disable all these validations. Just send the download token even if the renter is not allowed to download the shard. Do we realy want that? Farmer should not have any incentive to disable client side validations.

[tempestb]

I would advocate trying not to punish RPi3 users if at all possible. It's a very cost effective way to run Storj Share without using a lot of electrical power. I realize that progress often requires additional processing and that in time, the RPi3 will be outdated, but it would be nice to avoid that as long as possible.

Thanks Kevin

[braydonf]

Started to implement the proof-of-work verification code at https://github.com/Storj/service-middleware/pull/16/files

[braydonf]

@littleskunk Went through and made some clarifications:

• The farmer does not need to repeat the proof-of-work challenge for PATCH requests to update the contact details. The motivation is mostly for there to be some identity cost to creating new nodes, not for updating information about an existing contact.
• The additional verification was added, challenges are removed once used, to avoid reuse.
• After implementing, looks like the nonce can be the salt.

[braydonf]

@tempestb An alternative to using proof-of-work is to implement SIP2, and/or the Storj Directory on Ethereum contract as described in https://github.com/Storj/sips/pull/20 However discussion on that is likely better in community chat.

[littleskunk]

Looks better. 1 and 2 solved. 3 would still be possible but the incentive is lower. 4 and 5 solved.

6 is still open. To be more clear: I have the implementation ready and tested. It is working. I am getting ~80% more shards. If I am forced to run this modification I will do it even if I know that it will have negative side effects for the renter. a) The renter will get a download token from me even if I don't have the shard. The renter will than get many download errors and has to retry several time. b) A hacker can request a download token too. If I try to validate the contract details, I have already lost the responseTime battle. I would have to disable this step as well and deliver the shard to the hacker.

Solution: We can't use responseTime at all. Don't give me the incentive to disabled client side validations.

[littleskunk]

The trustworthiness of a farmer or client can be determined by grouping exchange reports associated with that farmer or client into pairs (each exchange report from a client will have a corresponding exchange report from a farmer). By calculating the number of exchange report pairs where a particular reporter (farmer or client) disagrees with its counterpart, and dividing this number by the total number of exchange report pairs, a trustworthiness percentage can be found for a particular farmer or client.

7.) I need only one farmer and one renter to manipulate the reputation system. My renter will upload shards 24/7. a.) If I hit my own farmer they will both send the same report. The transfer was fucking fast and we have a realy fast farmer here. b.) If I hit any other farmer I will slow down the transfer realy hard. At the end again farmer and renter will send the same report but this time it will look like the slowest farmer in the world. At the end my own farmer will get a better reputation while all other farmer are getting a bad reputation. If my own influence is too low I will find some other farmer joining my game. Together we can manipulate the system even better.

PoW has nothing to do with the reputation system. We can as well remove it. What would be the problem without PoW? I think PoW gives me an advange. I can use my GPU to stop new farmer from being able to join the network. That is a nice containment and will allow me to manipulate the repuration system even better.

[braydonf]

Using exchange reports to sift through to get the truth is an area that needs further exploration and testing. This SIP lays the groundwork for an improved reputation system to be used to select farmers, however not the reputation system itself.

Some of that client side validation is to the benefit of the farmer to verify that the requester is the same for the purpose that such download will be accounted and reflected in payouts.

Currently there is near zero cost to spin up new nodes to create contacts for a higher probability of getting contracts. Each contact would still need to go through benchmarking phase. Having a small cost to add a contact is for limiting flooding the benchmarking pool of contacts, as currently the is near zero cost. If using proof-of-work for rate limiting becomes problematic can consider other option.

[littleskunk]

As farmer I will have no choice. I will be force to disable all client side valiations. I think I can implement a solution for 6b on starting the transfer but it is up to the bridge to fix 6a. A better solution would be a reputation system without any responseTime incentive. That would allow me to run any client side validation you like.

You are right about PoW. I missed the point that I could manipulate the benchmarking pool. An one time PoW should solve that problem.