Maybe you are right, maybe paying is not a good idea but i need to think about it deeply.
Anyways… I’m talking about two differents scenarios:
You loss AC power, there are no chances, you need to refill your vaults.
You WANT to reboot your pc so you tell that to the network, the network check your status and gives you X seconds (X’ safecoins per minute/hour) to reoot without loss your chunks
This post is a reply to yours before your edit. 
Once again I like this idea and from reading other older posts I will not be alone.
Yes I know
But the difference on the network is not as much as one might consider at first thought
Power loss
restart
The processing required for crypto signature granting/checking is very small and all other parts are normal procedures for the network. So many of the attack vectors are the same for this feature added as for not added. The attack vector would be opened if you delayed the normal procedure for vault going off line. I submit to you that normal procedures for vault going offline must be followed for reset or not.
The downside of following normal procedures when vault powers off, restart or not, is that when the vault returns some of the chunks will have 5 copies on the network and then the vault is competing with 4 others instead of 3 others when those chunks are requested. But this is the penalty paid for the restart, rather than spending coins.
My thought is that if you charge a certain number of SAFEcoins, then the feature will be rarely used and less so as SAFEcoin value rises and bandwidth costs lowers.
This (many minutes to hours) is probably the most unlikely reason to spend extra coins for. After even a few minutes the network would have recreated all the chunks in other vaults and spending extra coins will make no difference to the network in processing or otherwise.
This is the issue, if we ask the network to hold back for X (magic number) minutes then we open a security hole and even a wee tiny crack can be enough for some. So the network works as fast as possible to make copies of all the chunks. It then complicates matters to know what you should have and what you have, so end up going get requests or asking if you should have chunk X Y Z etc. this causes traffic and requires nodes hold more state, so the avalanche begins really.
This is where non persistent vaults saves almost 20% of network state, ever % is a target for us and the network to get rid of. It’s always a balance though, but less is best in nearly all cases with state.
The system only knows a vault is working correctly when the chunk is retrieved. - the system cannot create any “checksum” of a vault because the system does not know the chunks and has no way apart from asking the vault.
Ok, got it. thanks for clarification 
@stupidcache I think you should continue to develop your idea for allowing machine restarts.
You now have some additional information/ideas to work with. I do not see the any problems with the network carrying on as usual while your machine resets and having an extra copy of the chunks when your machine returns. The majority of the processing will be in the vault itself and the network signs off on it. I suppose the trick is to work out how the network can do this without the need to hold state info itself. (maybe a signed SD is written that is signed off by the network and the network can use when the vault returns to check state, rather then the network holding state info. There is the spend cost, the cost of the vault writing a SD. Next problem vaults do not spend anything coins or resources)
The issue that could cause problems is that if you reset too often in a short time then there may be many more copies of your chunks than desirable. But with non-persistent vaults this may not be an issue for any unreasonable length of time. One solution might be that you have to be online for at least a certain time before allowed another controlled reset. But that needs investigation.
I agree continue to look at this, a word of warning, please check out “traffic amplification attacks” when working in this area (can you create traffic easily on the network, by switching your machine off and on repeatedly). These attacks can be mitigated, but mean holding even more state and potentially even (dare I say it) timers. So please do look deeper, this is just a bit of info to keep in mindd
Maybe a solution for the maintenance restart (not for the power outage) could be to allow two machines on the same LAN to impersonate the same vault (with the same credentials). They could sync their chunks quickly over the LAN, and while one is restarting, the other one serves them… like a “cluster vault”…
Serious farmers should probably use external harddisks for this reason.
Doubt that would help, unless the vault s/w is installed on the NAS. The vault keeps its storage on disk anyhow which remains on restart.
Would that not require the network to specially authorise that? The 2 vaults are seen independent of each other by the network, and moving data between the two would not be recognised by the network.
The idea is to essentially virtualize the vault on your LAN, the network won’t know which machine is actually behind it.
I will have to try that one day
Is it true Google makes money off people using the internet in general, or do you they make money when people directly or indirectly use their services or come across sites using their services, which make money off of the data taken from those interactions? Would Google do well on a completely anonymous and private internet? I don’t know.
I get the impression most of their services are dependent on a stream of freely collected data that they can utilize for business purposes; that they put out free services so they can capture data, not to provide products. I know that not all Google services are of that nature, but I wonder where the balance of profits come from–data theft profits vs service offered profits. This article goes over some deceptive practices of google, data-mining students using educational products, even when the ad-delivering option is turned off. http://safegov.org/2014/1/31/google-admits-data-mining-student-emails-in-its-free-education-apps