Here’s my two cents and a recent consideration: a get request triggers a farming request, but by using the hash of data from the get request and client_requestor information the actual challenge goes to an unrelated chunk (this will almost always point to empty address space, but a close group for this farming_challenge chunk does exist. This group can be tasked with verifying the safe storage of the closest nearby chunk.
Such an approach retains the coupling of farming challenges to the actual usage, but decouples any attack of this kind, where you try to focus an challenge on chunks you hold.
get_data request -(irreversible hash)-> farming bounty placed on the network; removed after failure or successful completion
Once you “win the race” by being the first to return the chunk, you are allowed a farming attempt.
Your farming attempt involves reporting to your close group on a chunk that doesn’t exist, found by hash of data + requester data, but has a close group in xor space none the less?
I feel like I am missing another step here.
As long as I can force my vault into answering more get requests than it would normally, it shouldn’t matter what the challenge looks like after that. I just want to be able to be challenged as many times as possible as quickly as possible.
You mentioned in the “deletion” topic about encrypting the vault itself as it sits on a farmers harddrive. Will that be checked cryptographic periodically? As someone inclined to attempt an attack would strip that from their local code first thing. If he could still function as a “proper” node without it, it seems like adding unneeded overhead that can be removed with little effort.