Depends on the node chosen by the elders and there is no reason to assume it will be constant. Remember the network is dynamic and no reason to expect that a 10 hop path will remain constant
Anyhow its not as important as the fact that finding which chunks that are in your vault is not easy and just finding one before being relocated could be pure luck.
I think you are playing a different game than I play here.
Simplest case would assume certain conditions. Those conditions that I use for my reasoning, are those of static network.
Additional complicating factors were accounted for separately (such as the dynamics of nodes leaving and joining, other clients requesting the data).
This indeed is another factor. I didn’t mention it, but was also assuming that you can issue requests on individual chunks by knowing the chunks (as one would when owning the vault holding them).
If it is from the beginning not possible, even with custom client code, to issue requests for individual chunks in the network, then it is completely infeasible to gain farming rewards this way I would say.
Hmmm - there must be some sort of database where the chunks are stored - if I wouldn’t know which chunks I store I couldn’t deliver them 
Small maps are just one chunk/data map - so I could only request small files below 1mb but with those it should work after analysing my vault container…?
Ps: damn I should stop throwing stuff in without reading the rest first… Sorry…
Each Vault stores the data whose XOR address is close to its own XOR address. Similar to a farmer whose job it is to take care of the land around his house.
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…
Ps:
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
So I need an elder vault to pull this off? That would not precisely be mitigating but making sure that farming will become centralized…
See my edit above to give you an idea of how bad it can be even if you knew one chunk.
Frankly it will be like the script kiddies who get tired of DDOS a major site after a day or two or three. How long would you pay to keep up such an gaming attack?
You assume that I don’t know more chunks than can be cached
What makes you so sure about this? The network doesn’t know time - the only thing making cache expire should be volume (i wouldn’t see why here suddenly time should be relevant)
Time has always been significant for caching analysis. That doesn’t mean the network needs to know time.
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
No it hops back as part of the requirements for anonymous data and not allowing any node knowing the source or destination
What if my client is sitting in the neighbour section? Clients can reconnect as often as they want if I’m not mistaken…?
Have to ask someone who knows the code. We’ve always been told the number of hops is on the order of log of the number of sections and required to be a few in order to provide the anonymity.
For your example its easy to do if the section tells the node to send it to a section not on the actual path and then that section hop it as normal
I always assumed the log n is worst case/longest path to chunk discovery not a stated goal
But routing along xor would be only one path from the neighbour section and only one hop…
This defeats the principle of anonymity