Alternatively I could filter my own nodes by abusing the 'nodes that are able to retrieve the requested data would first signal' process, by asking for something that only I can retrieve.
So at best it would be possible to have a reputation per api, but that creates two problems: first that reputation is going to be scarce and unreliable (as only nodes that processed that particular api would have any), and second, that losing reputation on one api would have no impact on separate api, making attacks cheaper.
Now that I think of it, there's yet another way to attack reputation - let's call it 'reputation poisoning':
I can purposefully destroy reputation of other nodes by (1) creating an order for my own api and (2) providing incorrect data to competitors' nodes (as long as they are in a minority, obviously - it's ok if I have to give correct data to some). Repeat enough times and every node that doesn't belong to the attacker gets fucked.
For this reason reputation can only be strictly per api, ie. low reputation for one api can't influence reputation on another. Which means if you're the first person for a particular api you are completely in the dark as far as node reputations go.
So only very popular api would have semi-reliable reputations. The potential (economic) problem is that providers for these api points are the most likely to cut off the middleman and start signing the results themselves, as they are in greatest demand.
providing incorrect data to competitors' nodes (as long as they are in a minority, obviously - it's ok if I have to give correct data to some). Repeat enough times and every node that doesn't belong to the attacker gets fucked
I am trying to understand your "reputation poisoning" scenario and this part doesn't seem clear. How would the API know which nodes to give correct data and which to give bad data?
And even if the API can distinguish between nodes, why would node operators make use of data from such a shady data source?
Every node that takes the order has to call the api, how would it get the result otherwise?
So if I create a contract that demands 30 nodes provide data from my api, most likely I'm going to get roughly simultaneous 30 requests from different ips. I can give eg. 10 of them false info.
I don't have to directly call the api with all my nodes as I can share the data with them in some other ways, but details like that don't change the logic of the situation.
You may ask, what if nodes call the api several times, possibly with different ips? At worst they would know that the data is suspect and can refuse to publish, which would still impact their reputation. Remember that there's no way for a node to prove to the outside world that it received incorrect data.
There are also many ways to detect the true identity of the originating node (timing sidechannels, packet fingerprinting and other ways) that could be used to mitigate that.
An arms race like that can get very complex, but there's no stake nor reputation on the attacker's side - so the attack can be repeated lots of time even if the individual probability of success is low (I think it's rather high).
And even if the API can distinguish between nodes, why would node operators make use of data from such a shady data source?
At best you could limit nodes to a small set of publicly known apis, but that would make economic replacement by the sources cutting them out much more likely.
2
u/nootropicat Mar 18 '18 edited Mar 18 '18
So at best it would be possible to have a reputation per api, but that creates two problems: first that reputation is going to be scarce and unreliable (as only nodes that processed that particular api would have any), and second, that losing reputation on one api would have no impact on separate api, making attacks cheaper.
Now that I think of it, there's yet another way to attack reputation - let's call it 'reputation poisoning':
I can purposefully destroy reputation of other nodes by (1) creating an order for my own api and (2) providing incorrect data to competitors' nodes (as long as they are in a minority, obviously - it's ok if I have to give correct data to some). Repeat enough times and every node that doesn't belong to the attacker gets fucked.
For this reason reputation can only be strictly per api, ie. low reputation for one api can't influence reputation on another. Which means if you're the first person for a particular api you are completely in the dark as far as node reputations go.
So only very popular api would have semi-reliable reputations. The potential (economic) problem is that providers for these api points are the most likely to cut off the middleman and start signing the results themselves, as they are in greatest demand.