Gaming farming rewards - cost for GETs

Features
1

Because of the discussion about gaming or PtP I was just thinking about the farming reward and that it’s indeed gamble I’d think :face_with_monocle:

So I would think that gets should involve a cost to mitigate this… Cost doesn’t need to mean safecoin but could be computational cost as well - so if with every get you’d get a computational challenge (something someone requested to be computed by the network => decentralised computing) that you need to resolve before the next get there would be a cost involved in performing gets and at the same time we’d have decentralised computing implemented in the network

when more than (e.g.) 17 gets get the same computational task the network is charging too much for computation and if its less than 12 computation is too cheap because the network is flooded with them

If someone wants to game farming or PtP (ptp would be less profitable than the farming reward I’d assume) he’d supply a lot of computing power and would have a cost there +the network / the world would benefit from the computing capabilities too which would mitigate the impact/attack vector

Ps: might just be a mind fart … It just was something that occurred to me and I thought I’d share my thoughts (and if the computational stuff is handled by the client libs automatically the implementation would be in Rust and platform independently and independent from the language used by the app/website… Just something that happens automatically in the background

1 Like
2

Some devices likely won’t be suitable for computation. Maybe they are too slow, or maybe they need to conserve battery charge. So I think it would be good to have the option of just attaching a fee.
This relates to this post by mav about how to structure a queue of requests & events that occur on the network. In the early days of Bitcoin fees weren’t needed as the blocks weren’t full and block rewards were high. We hope for greater scalability in SAFE, but there should be some similar mechanism in place to handle situations where the network becomes too burdened, even if the network doesn’t end up reaching that level of workload.

1 Like
3

My thoughts apart from the fundamentals, which did not express cost as in safecoin but cost, are

  1. Energy
    If you increase the computational efforts for each GET then this increases the energy usage for each GET. On a small network then this might be able to be absorbed.
    But we want safe to be a global network so then these milli watt seconds of energy all add up over millions/billions of GETs per hour when the network is global.
    Solar argument does not cut it because computers in general are not solar and only if the local energy company uses solar will there be solar.
    But the heat dissipated by the device is also important.
  2. There will be an extra force in the disparity between the haves and have nots
    If every device was reasonably close in computing power then this would not be a point.
    But the devices range from those that can only just be expected to run client code as it is, thinking of phones and IoT. Compared to desktops that would laugh at the extra work required.
  3. How would this be enforced on the device? The attacker could have a central desktop to do the computational work and small cheap devices to do the actual attack.
1 Like
4

Which would be okay since he does the computation for the network - how he manages the processing power is nothing the network needs to worry about

Is that fairer than letting the haves increase their income through excessive GETting of the data stored on their vaults? (just that here the workload is distributed amongst all nodes instead of mainly increasing cost for the attacker+increasing the processing power+income there for the network)

Again - the main difference would be that the heat/cost for GETs is distributed amongst all nodes as of now - if the requester needs to do at least a little bit of (useful) work this would make the cost being mainly a cost for the attacker and +it would strengthen the computational layer

I don’t say we should implement something like this from start - the sooner and simpler we start out the better - but I am not sure if a gamable farming reward doesn’t result in a very strange situation where we wanted to reduce the effect on environment and make a more reasonable concept than pow but all farmers do GETs like crazy to increase their income and generate a lot of wasted energy on a global scale (which unlike pow doesn’t even secure the network) +cost for this is distributed amongst all nodes and the non professional farmers are paying more than they earn even though they just offer unused excess space…

4 Likes
5

It’s an interesting line of thought rid, but I think we need to separate out two aspects: 1) DDOS/abuse and 2) using network resources.

I think it’s critical that simply using networking resources is free, from a pragmatic onboarding point of view but also from an admittedly ideological point of view where access to uncensored information is something like a human right. I would rather that people be incentivized to participate in the nodes/provision side… bittorrent is fantastic when everyone seeds and that is the feeling we should be going for.

On the other hand, DDOS will absolutely be an issue that needs to be mitigated, but I believe that there has been some discussion about how to handle such malicious behaviour.

6

Ddos can probably be taken care of by rate limiting… The thing with gets that result in farmed safecoin is that profit is generated/maximised by generating a small get that keeps the network busy

(and because cached data doesn’t bring profit I’d try to always request new data which then needs to propagate through the network just to get thrown away by me again)

7

I think what I’m about to suggest might have already been mentioned in one of those discussion. But anyway:

I think this ties in very well with health metrics. To me it seems of utmost importance that the network has a notion of its own health, on various levels.

A section could monitor the strain its under. This allows for preventive action to take place only when it’s needed, and thus avoiding waste of resources.

So, if sections monitor its traffic and load percent of its nodes, it can at a certain level start introducing breaks. Remember: Protecting the network is the ultimate job of a node, then IIRC, the section and then the node itself.
I would say this ultimate job of a node motivates introducing a break in form of a fee, when a section is becoming strained above a certain level. Given that the section is of adequate composition wrt node performance: better than to have it succumb under abnormal load, is to measure a device to protect itself and fend off the abuse.

Instead of requiring all clients to always pay the cost of CPU work for a GET, let sections apply fees to GETs whenever they cross a certain threshold of load.
All such evaluations should to maximal possible extent be dynamic. The threshold must take into account what the resource proof looks like, and thus the resource proof should be dynamic in some sense so that it can follow the presumed increase in general performance of nodes over time.

Example:
All load over 80% could result in an exponential increase of fees added to GETs.

Any clients not involved in the presumed abuse would be punished as well, but before being absolutists about that (“no fees for GETs”), let’s consider if it is at all possible to protect the network at no cost at all. And maybe that then is a reasonable cost compared to having the sections be susceptible to such abuse?
Now, naturally, before preventing the abuse, it should be shown that the abuse is actually feasible.

(This thing doesn’t however address the mitigation of fabricated GETs on a vaults own data.)

Edit: As the closest nodes covering all the paths from the entire network have their caches filled for all held chunks, there will be fewer GETs coming through that ring of defense, and so the load would drop correspondingly.
Section size (assuming the section members, and edge case members of neighboring sections are the closest nodes to a given node) as well at cache TTL, together with number of chunks held at the node, would decide what maximum number of requests per s could actually get through the cache ring of defense.
So if the abuser has a vault storing x chunks, he would like to do GETs of all those chunks in parallel, from P = ([Section size] * ([Neighbour count] + 1) - 1) distinct paths passing each of the individual P closest nodes, to maximise GETs per seconds, and thus rewards.

This would also be the upper limit of any legitimate rewards.

8

Can you give details on exactly what part you think is game-able?

9

I would think it is something like this:

As the closest nodes covering all the paths from the entire network have their caches filled for all held chunks at a given vault, there will be fewer GETs coming through that ring of defense, and so the load would drop correspondingly.
Section size (assuming the section members, and edge case members of neighboring sections are the closest nodes to a given node) as well at cache TTL, together with number of chunks held at the node, would decide what maximum number of requests per s could actually get through the cache ring of defense.
So if the abuser has a vault storing x chunks, he would like to do GETs of all those chunks in parallel, from P = ([Section size] * ([Neighbour count] + 1) - 1) distinct paths passing each of the individual P closest nodes, to maximise GETs per seconds, and thus rewards.

This would also be the upper limit of any legitimate rewards.

So, if the reward exceeds the cost of maintaining that number of clients doing the requests, it could be profitable.

Not sure I’ve got all the assumptions right here though.

10

Doesn’t look like you took into account the multi level effect of caching.

It could end up that all chunks are cached in the hop nodes on the way to the vault.

11

I think I did, when requiring distinct paths. This requires a certain distance between the abusing clients, as to all reach the P closest nodes from a distinct path.

12

So, not only does it require a certain distance, it means the network must be of big enough size to allow such a distance, as well as there being a way for clients to position themselves at these distances.

If they cannot other than by flooding the network until they randomly have those distances with at least one client (which would certainly not be profitable), then the upper limit would be lower.

I guess network size would determine likelihood that P clients where at a sufficient distance as to have distinct paths to the closest nodes. :thinking:

(But I’m forgetting how clients “get a position”. They don’t join any sections, so what is the procedure for having an entry point into the network, through which the GET paths to the rest of the network are established?)

13

But your calc is one level.

For any one chunk there will be a number of possible paths depending on the initial path of the request. And the resulting path may depend on the particular vault that responds to the request the quickest.

For instance there may be 3 nodes the client passes requests through and if different XOR regions for those 3 nodes then there will be 3 possible paths. The first vault returning the chunk goes through one path being cached through the particular nodes passing on teh chunk. Now the second time that particular chunk is requested it follows a different path resulting in no cache being triggered. This time perchance another vault responds and it takes a different path/set-of-nodes and that path gets the chunk cached.

And the third request could happen to take the 3rd path and the return fills another set of nodes’ caches

From here the requests for that particular chunk will come from the caches and if continues to requests then all nodes in the sections for the return path will be filled. More like all the caches of on the order of (hops * section size) nodes. The neighbours is not really involved since each hop sees the connection from the previous hop and these are the neighbouring nodes used, not all the netighbours.

So then all requests for that particular chunk will be coming from the nodes closest to the requester and the nodes closer to the vault will slowly release that chunk since the reuest is being satisfied by the closer nodes.

An in the end the vault holding the chunk sees no load at all, but a section or two worth of nodes will be semi-randomly filling the request.

Then if multiple machines request that particular chunk then more sections will have their nodes caching the particular chunk and the vault will still see no requests done on it. Only when a new machine connect (or reconnects) could the vault see a request. And of course another of the 8 vaults could be satisfying the request.

If the requests are slow enough for no cache to retain the vault then this means that there is a limited number of machines doing the request (on the order of the total number of sections in the network) and doing it slow enough. This is really a very slow rate of requesting and the rewards will be minimal. Even a 10% speed increase could cause caching to fully kick in again. Also this slow rate they can request will be dependent on other activity through those caches.

Then there is the problem of there being 8 or more vaults with the chunks.

Is it worth the attacker’s time and money to attempt this juggling act to have attacking machines tied up trying to make gets happen on that particular vault?

14

Assuming static network, there is only one closest path between sites in XOR space.
So, if you have 1 client, you will have 1 path.

The upper limit of number of distinct paths are limited by the number of closest nodes to the vault (P in the example above).
Additionally, as to be able to maximize requests, you need to have P clients at sufficient distance from each other, as to each hit a distinct node out of those P closest nodes, at a distinct path end to end.

When you have this, all you need to do, is to request each individual chunk at a slower rate than TTL, for you to be able to get rewards from the vault you own. Statistically you would get 1/8th if all copies are held by equally performing vaults. You could perhaps increase it to 100% of requests, if you manage to provide a vault that is performing better than all the other 7.

The question then is what costs are associated with getting clients into that optimal position, or find a minimum cost where there’s a convergence between client positioning effort and likelihood for good distribution of P paths, as well as any costs of beefing up the vault as to be first to serve, and then compare to see if the rewards are enough to cover the costs.
Since the rewards depend on the farming rate, the difference between cost and reward would fluctuate with farming reward. At some time it might be profitable.

Edit:
Complicating factors reducing profitability of your setup, are:

  • Network is not static, so nodes leaving and joining means new paths, which increases costs of keeping your clients placed where they do not have intersecting paths.
  • The data in your vault is not provided by you, so you have no control over the rate of requests from other clients in the network. Those requests would non-deterministically introduce longer total times before cache expiration.
1 Like
15

Cache for sure will be limited - if my vault stores only 10gb of data do you think a cache would be large enough to kick in? (edit: sorry didn’t have a chance to read everything - just saw cache mentioned and thought I’d throw in that I think the effectiveness is very limited by the size of the cache - will be back/read the responses later when I get a chance)

2 Likes
16

One path if specifying sections, multiple paths for the nodes in the path

17

if my vault stores only 10gb of data do you think a cache would be large enough to kick in?

I’m trying to figure out how to put it differently, because I think the answer to that question is in my previous posts :slight_smile: I don’t mean to be facetious, I just struggle with simplifying the explanation :slight_smile:

Rate of requests you can do on each chunk, depends on section size and TTL of cache, as well as network size and the position of your clients.

2 Likes
18

All good then I’ll just read your last comment completely when I have a moment

1 Like
19

Realistically you are only ever going to find a very small number of chunks in your vault. And then you get relocated regularly losing all the chunks in your vault and it refills.

Basically its trial and error to finding the chunks in your vault. Maybe only chance too.

20

Hmm :thinking:

We have the simplest condition of 1 vault owned by you.
We assume a static network, so no nodes are leaving and joining, and your vault is not relocated.
You have 1 client, at a fixed position.

With this, there will be 1 single path from your client to your node.