Different model of economy (Pay per Time)

Disclaimer: this is NOT a proposal to change the planned model of issuance of Safecoin. This is a merely theoretical discussion that may serve to fork the network or just for the sake of discussing.


I wondered whether the main problem to switch from pay-once-store-forever to pay-per-time is network security (time stamping). Probably it is, since on SAFE as it is designed currently there is no relation between me and my files but a key that I own and that allows me to access my files. In that case I see that a Pay per Time proposal doesn´t make a lot of sense. Still I see some merit to think about it if there is some solution to make it possible while delivering the same secure access.

Imagine that unlike now there was a set time in which all SAFEcoin are distributed. Imagine that time would be 4000 days (~11 years) and distribution would pay out in a curve that reaches maximum distribution after 5 years and eventually slows down until all coins are distributed. These coins serve as “subvention” of farmers cost.

To put content on the network, you load money to an escrow address from which money is constantly discounted. The content is chunked and distributed. Farmers are concurring to host chunks because this is what gives them money. Farmers clients can adjust the minumum payment so the price is eventually sorted out between those who can offer the most efficient farm. At idealistic farming levels, the price per GB drops close to zero - if there are only commercial farmers it will be slightly higher than cost per hardware + electricity and bandwidth.

Unlike the current design of Safecoin this sets the owner under pressure to sustain the content on the network by loading money to the prepaid address - so this is a very different economical approach. However, since this can be done with a public prepaid account it doesn´t have to be done by the owner alone: Imagine some whistleblower uploaded material onto the network and the messenger gets killed, other people could provide the account with coins to prevent the files from expiring.

I also see another merit: Let´s say I don´t want to pay anything for hosting my files anonymously over the network I could simply upload 10 GB of files and host 40 GB. This way I would always earn what I pay, but have my files stored securely over the network. In case I have to shut down my machines for some reasons over some time, I disconnect my devices and load some extra coins to the prepaid address. Let´s say I moved somewhere and had to drop out 1 week, then I will simply host 80GB for one week after that and I am back again at about zero (if exchange rates weren´t massively volatile - if you counter-host your stored data directly you don´t have that effect).

The advantage over the current concept of SAFE is that the network cannot “collapse” - however, if the price isn´t stable (which may be the case, particularly at the beginning) it may lead to unpredicted discounting (or hoarding) of prepaid coins. In a sense that is inevitable, but I think if prices are highly unstable this would destabilize the current model as well. Also, it´s possible to hedge against that, allowing for more network stability. Anyway, the economy wouldn´t depend on exponential reduction of storage cost.

The main advantage I see is that you can run the network at 0 cost, once you decide to quadruple your hosted share.

1 Like

Since @happybeing linked this post in another thread I started thinking about deduplication. Deduplicated content in this consideration would mean that users share the same prepaid address. It is therefore important to stress that once money is escrowed on that address it cannot be taken back (at least in case the content is deduplicated).

It is possible that in case of shared content users will not come to a consensus who pays what to sustain the files and then the content drops out. That´s a side effect of expiring shared content and I think it´s fair if that happens.

That is the main reason

You do not have a crypto key as such, but rather a data map is stored by your client that maps out the chunks that made up that file and holds the encryption keys, but can be given to anyone if you wish.

If two people store the same file then the data map and keys would be the same no matter who stored the file first.

The network does not know how many people you have given (or sold) the data map to. You may not even be the “owner” any more.

What if I did 6 months programming and sent you the work (data maps) but only paid enough for the files to last another week. I get my money, he assuming the files will remain calls his programming auditor to review the code (sends him the data maps). but Boom time is up the files are gone. It would be no good copying them on the network because dedup kicks in. The person who paid is not savvy enough to have copied the files onto a memory stick, hell he barely understands how to open a text editor let alone much else.

I did suggest previously that there be 2 types of file store, 1 normal as per SAFE and temporary class that does not get propagated after the set date. The group decides if the chink is past its due date. Then payments are reduced for temp data. That way both types are handled by the network exactly the same, except that when the network goes to replicate the chunk on a churn that the group drops it if consensus is it is past the use by date.

I´d think that´s pretty unlikely to happen in a professional context, since either the network is used by people who are fully aware of those problems OR it is used by the mainstream - in this case there are already solutions that will prevent surprise deletion of files to happen (I already mentioned hedging).

If I was the person who asked you to do the programming, I´d copy the files immediately and put them to a place which I have full control and oversight. You don´t just put that amount of ressources to an unstable place or make sure it is safe.

Yes, my formulation wasn´t correct.

As I wrote, in that case both people would share the same prepaid account. Unlike the discussion on temporary free files, there´s no suprise time-out. You can estimate when time runs out.

Is that a problem? It is. However, it is less problematic than it is right now: In the past, many people lost data because they stored them on Google Drive or Dropbox and those enterprises had issues with their infrastructure. Anyone keeps you from running a hosting enterprise on SAFE, build your brand and earn trust. If you drop out, the files are not lost - they are just propagated to the next vaults. Of course this may cause trouble and maybe your deposit is used quicker/slower as you intially estimated, but it´s still way more secure than the current server structure. It´s a distributed RAID which you pay for and may earn on.

Just a trivial example of potential problems not realised by people being given a file.

Some of what I said was what you said

Sorry I did skim over some of what you wrote, but this sounds like you have a link from the stored file back to the “owner”?

I agree that there maybe some merit in timed files, but if you link back to the “owner” then you lose a significant benefit of SAFE. Would people be happy with that, they might. I’d rather see a date of expiry stored in the chunk’s meta data, so no link exists. De-dup cases the data lasts for the length of the longest paid.

I’d say you would need payment up front to solve the post payment issues (kept state, link to owner, etc)

They are my opinions and not criticisms of your idea. It may give you ideas though.

Don´t worry, I read your comments as such.

Well, since I can´t speak 100% technically, I am unsure whether it can be done, but I didn´t think about linking “owner” and file. Instead of only receiving a data map to the file, the uploader also receives a data map to the prepaid account, which is linked to the file. Once the deposited coins run out, the file expires, but it doesn´t matter who deposits money, so there´s really no direct link between individuals/users. That, at least, was the idea.

1 Like

Sorry, but this proposal already discussed months ago.

And, as I said before, this proposal broke the backbone of the SAFE network.

1 Like

I read that discussion and I don´t see how you convincingly explained why the proposal broke the backbone of the network. The discussion ended with you suggesting @tfa should fork if he doesn´t believe you. Not too enlightening. I am not saying you are wrong, it’s absolutely possible I fail to see the obvious.

I see the problematic part, however I wonder whether there is a way to deal with it. My data map knows two things: where the encrypted chunks are and the hashes with which they are encrypted.

Let´s say each and every chunk on the network has to be supplied regularly with a constantly changing amount of Safecoin to survive on the network. In this case I only need a decentralized app that provides chunks with coins. The app doesn’t have to know which chunks belong to each other, only which ones have to be served. This gives the user an idea how long the supply lasts at the current rare. This way its possible that chunks are " overpaid" because deduplicated content is paid multiple times without the different users knowing about each other.

This overpaid input may potentially be used for different purposes, ie

  • send back into the network, so farmers receive higher rewards
  • send to the original uploader as reward for virality or
  • simply stored as reserve so chunks may exist even if anyone pays.

Hedging could mean that farmers store outdated files without getting rewards to allow getting them back at higher prices once expired.

If I miss the exact point where there is a security breach, be so kind and explain. As I said, I don’t pretend to understand everything correctly and I’m looking forward to learn more.

1 Like

Personally I think the cloud storage solutions where you have to pay a monthly fee are horrible. It means you have to pay forever! And it also adds a cumbersome and problematic responsibility on the user to always have to make sure the data stored has been paid for, all the time. I’m strongly opposed to the SAFE network mimicking that model.

You know - someone HAS TO pay forever if a file is supposed to exist forever. The fact that you don´t like that, doesn´t make this truism disappear.

2 Likes

With the current SAFE network model there is only a cost for storing the data on the network. As I understand it, once the PUTs have been paid the data is stored forever for free. That’s superior to most of the cloud storage solutions today.

1.- Time is alien in the SAFE network. Can work with time as a vector but time in absolute, as your proposal need, is specifically forbidden in the SAFE network for several reasons. Is insecure as the time can link chunk and user, complicates the basic logic of routing because will need to significantly increase the number of messages between nodes and can be an network attack vector.

2.-Reduces confidence in the network and forces users to be aware of their data. In addition, as has been said several times, the cost of storing data reduces its price exponentially. That makes the cost will never be higher than twice the last exponent. In the end the cost generated to control the payment of the chunk may be higher than the simple storage.

P.S. In the beginning the name of the SAFE network was “Perpetual Data”. This indicates clearly that’s the meaning to create Maidsafe.

Source code is a pretty bad use case because of the small files.
Git (and commercial sites such as Github.com) solve the problem beautifully and for a very low cost (since you’d need a private repo) and for open source it’s even free with the whole stack integration (APIs, clients, QA, etc.). It’d take years to reach that level of sophistication.

I argued many times that data should be allowed to expire, aka Pay to Play, by the way.

1 Like

But is it really absolute time that is needed if all chunks all over the network need a payment every second. Isn´t that just relative time?

I know some people don´t like it - however, I wrote explicitly that I didn´t intend to stir another debate about changing the current model. It´s rather an idea for a fork or as alternative in case the current model fails for some reason - but security is, of course, crucial, that´s why I wonder if the proposal works out technically.

Well, I don´t trust in exponential growth on a linear timescale. People can say it several times or even more, that is anything but a bet on the future, not a natural constant and it´s weired if people pretend that it´s the same.

That is a very limited understanding of “free” and “forever”. Farmers have to pay for that stored senseless data and the current model assumes that it is just a form of risk management and future PUTs will compensate uneconomic PUT´s from the past. I am not convinced that this will work out, but it´s certainly possible. More importantly, it prevents users to host their data on a secure and anonymous network for free (because as a farmer you never know how much the reward will be and how much it will be worth in the future).

Relative or absolute, what’s the difference? It’s always time since the epoch, the first case just needs more compute to deduct A from B. The difference is probably 0 (single message can transfer the both values).

There’s a thread/topic or at least a comment on time on the SAFE Network, written by David, and he explained his concerns there.

How rude is that!

Yes, data storage gets cheaper and cheaper over time at an exponential rate. The important thing however is that users will own their data forever. If they have to pay for the storage continuously the users merely rent space instead of actually owning it.

They don´t “own” data. Reread the whitepaper. This discussion is drifting off-topic. I am not interested in a discussion about how good or bad other models are - do that in your own threads, please. This thread is about the feasibility of Pay per Time.

1 Like

You are aware of the stress that is submitted to the network if all chunks of data have to be checked at short intervals?
That means billions or trillions of new messages every second.
In the end, it will be more costly for farmers, in computational terms, this control that simply maintaining data.

The exponential growth is physical impossible but, in the last decades, the data storage follows this rule and everything indicates that in the coming decades will continue.
The future solutions for the SAFE network will come in archive nodes or other improvement but not in remove some of its best properties and complicate its functioning.

The truth is that you did and one old, boring and repeated. You complained that I suggested TFA should fork but, if you are convinced of your proposal, I can not do otherwise.

That’s what I commented about. It’s not feasible from an end user perspective since it will be like renting space instead of owning it. In the current model the users own their private data in the sense that only they have access to it. With pay per time, only the users have access to their private data but it’s only if they pay again and again, which is a renting model.

  1. Anyone forced you into the discussion. Since you took part in the discussion it is aparently not all too boring (counter-thesis: you don´t have anything better to do).
  2. My main point here wasn´t if Pay per Time is better, but whether it is feasible. You claimed it would necessarily cause a security breach, which it doesn´t in the proposal that I made. Whether it causes different troubles to the network is a different, non-security related (but still important) question with different solutions to discuss.
  3. You repeatedly argue (also in the other discussion) that Pay per Time would be against the “spirit” of Maidsafe, although I clearly stated that this is not about the implementation of SAFE as planned by Maidsafe. Either you didn´t read what I wrote or you simply prefer not to bother with other people. Both of which are not really compatible for a discussion.

Since you clearly stated that this is not an interesting discussion for you, I suggest you simply leave in your own interest.

The wheather didn´t change in the last decades. Clear indicator that climate change isn´t taking place. Funny that people who constantly insist on stringent argumentation come up with non-calculable trending assumptions.

One can easily extend intervals to longer relative time ranges - as I wrote above, that wasn´t really the point, was it? The main point was that you argued Pay-per-Time would necessarily cause a security breach, which it doesn´t.

Also, on a farming machine, which hosts 1 TB the machine would have to check the payment input for 1,000,000 files. HDDs read between 80 and 150MB/second. If the metainformation for each file is in the byte range (~100 byte) the whole information can be read in under one second. If you use an SSD way quicker, of course. If payments have to be served in one minute one wouldn’t even notice the “stress”. Of course, one has to see how “big” a Safecoin is.