Unless each chunk can be requested individually by some means, I think everything else becomes academic. But let’s continue assuming they can.
Somewhere in code base there should be something clearing up how the cache works now.
If it doesn’t cap somehow, all memory could be used up, which could make the vault crash, or just make it (and everything else) dead slow.
If there is a circular buffer (hopefully then with size based on the vault memory and not hard coded) well then the effect of this would be that effective TTL of that node’s cache when maxed out, is dependent on the size of this circular buffer. If requests are maximised and stored chunks size is larger than circular buffer max size in a node A, then effective TTL could be lower than the configured cache TTL. If there is however any node B on the path between client and node A, with a larger circular buffer, then that node will set the lower limit of the cache TTL on that request path (up to the configured TTL, which normally would be the lower limit).
This is not possible. Iirc all chunks in a vault are encrypted by another node prior to being sent to the vault. This would also include ownership and PtP or PtD related info. The farmer/vault persona has no idea how to directly request a chunk stored in their vault. Ie. “Pure luck”…
Perhaps a sophisticated oob collusion and fancy timing analysis to figure out if a particular public data chunk was stored in their vault could increase the odds but still very challenging. After that, the attacker needs to compete with the 8 other closest nodes and caching… Not very game-able, however the question of whether or not a ddos attack on a particular public data chunk could overwhelm the caching algorithm is interesting to consider. However I would consider this a genuine real time ddos attack rather than a gaming of the farming algorithm. I believe we already discussed methods of indirection and random relocation in a previous thread to try and stop situations like this.
I am not sure how you overwhelm the caching since the closet node to the requester will simply supply the chunk. You might get delays or dropped requests if it exceeds the node’s ability to supply the chunk, upload speed of the node will affect this the most. Then for a DDOS this is an effect for each of the nodes responding.
So any overwhelming is the inability of the close nodes to supply the data. This just has an effect on a relatively small part of the whole network. A bit like having stepped on a ant’s nest and have a few biting/stinging you.
Sure - but if my vault wouldn’t know which chunk has which xor address I couldn’t deliver the right chunk for the right request - so I assume every vault must have kind of an index which chunks it contains
If this would be the case I would say it’s indeed not a realistic option to request those but
And who tells me how I call the data I store and need to deliver (and how would he know that…?) if I don’t know the xor names of the data I store? Oo
I don’t know how it could be possible to hide from me what chunks I store… Sure the content may be encrypted but I know their names… Everything else doesn’t make sense to me…
Yes - simple setup - one client in a random position and trying to not become too fast in requesting data or pokering to to have more data than can be cached
The vault does not receive directly the request does it. The elders tell the vault to retrieve the chunk the elders specify and that means they apply whatever function to the address that was applied when telling your vault to store it.
Now if the section can receive 1 request per 10 minutes before caching elsewhere covers the request and it averages out which vault supplies the chunk then its once per 80 minutes or 18 gets per day for that chunk on your vault. Now if cache average keep time for the chunk is 30 minutes for any cache in the hop chain then its 6 requests per day. At say 0.00001 safecoin per get then you earn 0.0219 safecoin per year of gaming with one machine.
Now if you have 10000 machines and there are 1000 sections then there is a max of 1000 paths and many of those intersect so average of 10 paths out of the section with your vault. So we can multiple the requests by 10, but we have to extend the cache response time to at least double since there will be multiple cache paths potentially supplying the chunk. But if the requests are not coordinated then it may always be the cache responding even at one request per machine per hour or 2 hours since your 10 machines per hour per path will likely keep at least one of the caches responding.
Now your 10000 client machines will not be perfectly spread out across XOR space so the paths will not he 1000 but could be as low as 100 to 200 hundred paths and this makes the figures worse. In fact too many machines may defeat the purpose and you need to ensure each client machine is using a different path to your vault. But since you cannot know the path then thats out.
Have fun trying up multiple machines for a year to get maybe .2 to .5 safe coin per years (assuming get rewards are as high as 0.00001
My vault stores all data with prefix of my section but routed through xor distance to/from me right - I somehow thought of only one route because my vault has one position and stores closest xor address and it’s routed along xor distances
Are your data managers outside of your section? Or am I out of date with the concept of data managers? (or am I mixing stuff here now?)
I thought for a get there happens precisely one relay hop for anonymity on top so it’s not you who requests the data - but I somehow assumed because of the one additional hop the relay would be inside your section… Since this is not necessarily the case if you cannot know the section of your relay(s) my assumptions don’t hold anymore
(but if you can reconnect until you have a relay in a neighbour section it again would only be one path)
This graphic (old and dated) is what I base my mental image of the different intermediaries between a client get/put and stored chunk.
I think most of your concerns relate more to the game-ability of PtP than PtF. We want the network to be resilient against ddos attack. PtP gives a direct incentive for the attacker to try a ddos, but it also gives us a means to focus the discussion to creatively come up with ways to mitigate ddos. In other words, I see it as : PtP solution == Ddos solution and vice versa. So far it seems that caching is the primary defense, but there may be other ways…
Hmmm not sure it’s “that simple” - for PtP I need to try and get all my data into a singled vault (+relay to the neighbour section to only have one path and manage to get around caching) and reward is only 10% of the farming reward while if I own a vault and know which data I can request+ I don’t have the hassle & cost (with mutable data it’s easy to target a section but not that easy to target a specific vault…) and get 10x the reward if I manage to have enough data to blow the cache…