Indeed. At the same time, he does raise a fair point that if data is actually lost due to a massive network disconnect, the non-persistent vaults that contained that data shouldn’t automatically be emptied or refused by the data managers when they come online again.
2 Likes
This is key for the future, even persistent vaults would lose data eventually (this is what rank depends on). A network restart needs to work and this will require recondition the network has shrunk and we are holding relevant (or possibly relevant) data. I know we can recover from total network outage, but it is for sure after launch, but it is relatively easy, I just don’t want to get into the depths right now. Basically all you need do is realise your data is huddled closer together than your current close group. this show the network has altered a lot and the data you have needs republished, this also needs the data managers to agree the network has moved as well. So there are a couple of simple rules to be put in place here, but they are simple as they all should be.
This does not mean the whole network has to recover but it can in parts and as it does complete files will start to reappear again as it grows. It will also prevent safecoin xfers during this period as well as any contracts. So there are edge effects, but this is cool, it’s the stuff that makes it all interesting and just requires a few nights/weeks of deep deep thought. Not an issue at all and simpler than what’s already done.
7 Likes
You can’t tell who has and who doesn’t have such device. And having a device doesn’t prove anything - if you’re farming in country with a stable power supply you may do better than someone where extended black outs are common (even though his farm has a UPS).
Also, it is unnecessary to obsess over that - who doesn’t have a stable system, he’ll lose unsaved chunks and feel it on his virtual pocket.
This is awesome! One of the things I always hoped was that somebody could take part in being a farmer using their home computer and at least get some coins, without having to turn it into a server that’s on 24/7. I think this will really increase the degree to which people feel involved in the network.
4 Likes
I wonder how true is that. It’s something to ask people to share their unused disk space but it’s a very different proposition to ask them to use their unused bandwidth. If the bandwidth needed to farm increases a lot, many people could be put off by it. It would also make it less attractive to farm on a mobile phone.
Of course this is all speculation, without the details it’s hard to know.
2 Likes
The idea seems to be that people will only farm with their mobile phones when they have WiFi connection anyway. But you have a fair point.
1 Like
So this is to deal with the problem of an accidental fork caused by a massive amount of the internet being turned off or cut off from the rest?
That’s really cool!
Also when plugged into a charger. I see this is a way for phone companies to look seriously at providing phones to people that will be paid via safecoin. So a charging phone on wifi earns and the phone companies can stop giving the poorer rubbish cheap phones and give them higher speced phones.
I hope to make some way here as we launch. I see opportunities for some companies, particularly those who furnish the developing countries. When taken in conjunction with satellite/project loon etc. this all becomes the start of a movement I feel we should promote heavily, allowing those who currently cannot participate to fully engage 
6 Likes
PLEASE make this configurable and not fixed in the code. There nothing more annoying than having the bandwidth on 3G but an App that won’t use it, and only works on Wi-Fi (same with charger connection).
5 Likes
Well, it’s all open source, and the application level code will probably be easiest to change of all. So if there is demand for a feature it’ll certainly get in.
A lot depends (unfortunately) on the mobile OS they are notorious for demanding and controlling operation of apps.
2 Likes
@dirvine How will you resolve the issue of download limits both for desktops and mobiles. You speak as if Wifi connections offer infinite bandwidth and while they might offer more than a cell serive they’re hardly infinite, especially when you’re talking in several hundred gigabyes worth of space or a couple terabyes. For the mobile I’d imagine you’d be trading your cell bill for your internet bandwidth bill and hoping the latter would be cheaper than the former. As for the rest of us we;d be hoping we gained more value in safecoin than we lost in bandwidth costs and space on our hard drive. Hard drives prices might be coming down, bandwidth on the other hand is not. This is why I agree using persistant or non persistant vaults should be up to the discretion of the user. Non persistant would be good on a mobile but non persistant would be better on a desktop. If one has to sacrifice bandwidth as well I’d say a greater amount of safecoin should be awarded.
Even with non-persistent vaults it is for sure feasible to consider later down the line a challenge where you can republish and proof that you have chunks stored, even if your vault id has renewed.
1 Like
That’s a very sensible feature to add. I wouldn’t want to refill my vault after just a small internet hiccup.
About non-persistent vaults. What’s the trigger that makes a chunks move from a vault to another? Is it a constant, like every X minutes, or is it based on something else like a GET request?
Only if it loses the connection with the data managers I think. Churn for the sake of churn is inefficient, despite churn being somewhat useful in itself.
Wasn’t that already how it was suppose to work?
EDIT: Or before it was only when a Get request failed?
No, I think there was a grace period to reconnect?
Persistent vs non-persistent only means there’s no grace period anymore? It sounded like a more fundamental change.
It allows vaults to change ID on churn and this means we do not need to store private keys locally for the vault. This is a security issue as now we know the end user PC is very insecure. So if a hacker gets into your PC there is no key to steal. If they get it form ram then it’s still useless as your vault will be off then the session is gone.
The previous grace period basically did remove chunks as they were requested and you were not there and off the offline queue so there is a cost here in losing chunks but it’s a cost worth paying.
5 Likes
Just wanna make sure I understand correctly.
Before:
The vault’s identity (its private key) was stored locally. Every time it would reconnect to the network, it would keep the same identity. This method allows the vault to keep its address in XOR space. When a vault reconnect, it doesn’t have to redownload new chunks because its old chunks remain relevant to it’s XOR position. But if a hacker could get his hand on the private key he could then impersonate the vault.
Now:
The identity is new every time a vault reconnect. Its XOR address change accordingly and all chunks he use to hold aren’t relevant anymore to its XOR position. The vaults needs to restart from 0 getting new chunks from its new data manager. The advantage is that there’s no locally stored private key to steal, only one in RAM, and it is changed every time the vault disconnect from the network.
In the new model. It sounds like a good thing to disconnect your vaults once in a while to reset its identity. But then, you need to scrap all chunks you had.
How would that work then if your vaults now has a new ID which means a new position in the XOR space. Wouldn’t its old chunks become impossible to find since any request for those chunks would lead the request in another XOR region and never reaches the new data manager of the vault?
EDIT: Am I mixing up a vaults ID with its position in XOR space? Are they tied together like I think?