Non-persistent vaults

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 :smiley:

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?

This is a future thing and doable. Not for now. The rest of your assumptions are indeed correct. XOR space is where the vault ID lives.

3 Likes

As David already mention, these are future considerations and not for now. I also want to repeat that your reasoning is spot-on. A new vault ID would push the vault out of the XOR range for those chunks that it had stored in a previous life-time.

A first disclaimer, I am not convinced this is an idea worth pursuing; the value of old stored chunks is debatable as the network will have maintained the redundancy. Life goes on :smile:

How I thought it can work is: you would function as an ‘archive node’ (what the PMID node is becoming). Currently PMID nodes/ archive nodes are kept close (inside) the DataManager group; but it is likely that we will loose that constraint; The DataManager group is by definition close to the data name, but the archive nodes (already in the upcoming sprint) will not (all) be close to that original location.