This is again down to XOR, yes cache will kick in fast on that route (closer to destination route becomes more unique, i.,e a single cache hit), but there are separate individual routes to a chunk. Each of these will cache for 10 mins (current) but the app needs to be super popular to hit a cache and then only for 10 mins or so (also based on number of cache hits per route). So popular apps will get paid a lot and cache hit a lot too. So now imagine several popular apps, they all get the same chance and maybe by almost constantly cached and then this not so much used app, it all converges nicely, perhaps.
If it is lottery style it isn’t much of a trade off at all. If you app is popular enough to be fully cached, you will get the same rewards as any other app that is popular enough to be fully cached… It puts a ceiling on how big of a proportion of the rewards you get, but it really doesn’t limit the amount of the awards…
I don’t think they are arbitrary. You personas in the network that have the job of watching the files. If you had more personas to watch the caches you would get the point where you are spending more computing power watching the network than you would have running the network.
The numbers probably could be fine tuned and adjusted, but it is pretty hard to test any of that until you have a functioning network and a functioning currency.
Seems odd to me that people would get all worked up over something that isn’t written yet.
No, not really, it makes a lot of sense. (I include the devs of APPS in this)
If this is worth anyones while attempting this then figures are needed. Bit hard until the network is at least testable, but please, honestly please game the test system so that this issue can be highlighted.
Without people gaming the test system then the issues are not noticed and likely to end up in the release