Safenetwork sustainability concerns - Bandwidth has an ongoing cost however Safenetwork is a pay once, benefit forever model


#266

Even if the other option is also available? Remember it could be 5% or 10% of the cost, people will still be happy to choose that than paying 10-20 times more upfront. And it’s a win win for both cases. So yeah :slight_smile:


#267

Nothing in points 1 to 5 leads to the leap of paying for bandwidth or paying rental.

Put simply paying for bandwidth and paying rental will reduce the number of people using SAFE let alone storing on SAFE.

No and no again because of the complexity. Pure and simple the complexity will not help and at best be a zero sum benefit in numbers storing. I am talking of the complexity for people to use here.

But now if you look at the complexity for the network to continually scan for chunks that need rental paid and delete those chunks at the expiry time means the network is spending a lot on compute and disk work across every farmers machine, not to mention multiply the bandwidth needed to coordinate and reach consensus for agreing each and every chunk does or does not need deleting.

Then the human complexity to remember to pay for each chunk when it comes due. So if I store a movie and it takes 8 hours to upload then I have to one day sit and authorise rental payments for 8 hours. And do this every month, and just for one movie. Even if you could make an APP to sit for those 8 hours doing the payments (if you trust the APP) then your machine is on for an extra 8 hours once a month. Then multiply this for each movie you have ever uploaded. Well here is a radical idea, why not farm for those extra hours and just pay the full amount up front. Simpler code less attack surface and easy to understand in one package.

And like safecoin, it will take a very very long time for this final result to occur.


How does state pensions compare with a ponzi scheme
#268

Yeah I didn’t want to repeat the same arguments you guys have been saying for ages…which I agree with BTW.


#269

I think first of all you should try to think of a few arguments from the other point of view so you can understand better.

Second

Seriously??? Even when they have the option to choose? If they’ve chosen to have it monthly then you’re saying oh but it’s still too complex for them because they’ve just chose it and happy to have it that way. It may be complex to you but those who chose it may have different views. It’s not complex to use at all mate and it solves a significant potential issue. Also, you can say downloading the browser and using the safe:// protocol is also complex. Sending safe coins is also complex. You can pick out bad bits and throw every possible argument against any new proposal in order to defend the current state of the network and say it’s perfect, which is exactly what you’ve been doing for the past 260 posts. Not helpful at all. You don’t even think of any possibility of it 1. Not working as well as expected and 2.nor do you seem to believe there are ways to make it better. Because every single proposal made by me or anyone to improve the network so far has been rigorously defended by you. For what? So you think the current state is perfect and it never needs to be improved? It’s almost like some religious people protecting their religion saying it’s the only true thing and do not accept anything else besides their belief being true.

Which is why i suggested that you try to understand it from another perspective, because when you get into a Zen mode of defending everything and thinking the current model is perfect, you have closed your mind and no longer can the model improve. If the development team are like you then the network will never be able to improve… They will just reject ANY new proposal and find any reasons to defend their current model no matter how good the new proposal is or can potentially be if they actually thought about it and build new ideas on top of any new proposals. Which you also have not done for the past 260 posts… Simply been defending the current model. Instead of doing that why don’t you at least TRY to build on top of new proposals or give suggestions with your knowledge and also try to understand things from the other perspective


#270

Fair enough.

I still feel that the only thing that could be *needed* is the temp storage option when uploading. That way the person decides what private data is temporary. Personally, based on history, industry indicators, research projects, I believe that pay once and storing forever is sustainable for all the above reasons I gave and the delete is unneeded.

I also feel that rewards for attracting various groups to the network and to encourage them to store data/files/comments/etc is very appropriate. Like paying app developers when people use their Apps, and paying content providers for uploading good content that people want to view/download, and paying core code developers are possible and sustainable. They are a fraction of the amounts farmers get and dependent upon people using their individual contributions, so the better the contributions they make the more rewards.

And of course their rewards will be more scarce as the available coin becomes more scarce and as we’ve seen when a desirable thing becomes scarce then its price goes up. So even though at times the rewards become scarcer the actual monetary doesn’t reduce, and hopefully the same will happen to safecoin.

EDIT: I also see the payment for uploads is not paying for he initial storage but paying for the lifetime storage. The actual average incremental costs for farmers to store a chunk will be reducing over time and the coin you paid for uploading is used say 1/2 for the first year 1/4 for the second, 1/8 for the third and so on. So in effect there is always a little to pay the next year. Its the old discussion maths problem of a infinitely small frog that jumps half the distance to wall and that frog will never reach it. So too the coin used for uploading is never fully used in actual incremental costs. It might not be a reduction of a half each year for storage/bandwidth costs but it will be close to that and could even be better than that on average.


#271

Ok maybe I’ve overstated a bit in my last post I do admit but MOST of the time you’ve just been defending the current state of the network. And I just think honestly it definitely can be improved if we tried and got out of the thinking that the current state is perfect and need not change.


#272

OHHHH I just thought of another way. What if you made it such that when you pay to store things, safe coin enters a smart contract. And it get distributed like this, let’s say one safe coin is used. First year it gives the farmers 0.5 coins. Second year 0.25 coins. Third year 0.125 coins and so on. So every single year there will be some coins. It’s almost like bitcoin halving


#273

(I made a edit to my previous post)

Also we’ve had 3 years in the community talking about these issues and thrown back and forth many ideas along these lines and rental was not favoured are being a good option. This is one reason why the huge negativity by a few people towards the idea. Its an old one and discussed previously and found wanting.

But yes we need to consider new ideas, but remember the KISS principle. Keeping it simple has many benefits. So in general (yes not always but generally)

  • people understand it better
  • thus people are quicker to adopt it and remain
  • the code is much simplier
  • thus a smaller attack surface and this is so important
  • less opportunity to game the system, or said another way it is easier to make less gamable. More complexity allows more edge cases to appear and multiples the complexity to plug the holes.

Even your desire to reduce the initial upload costs for rental recognises that the costs to store for the initial time is not the cost that is charged. And so the costs for uploads includes the costs for forever storage and that incremental costs for storage reduces over time. Thus charging the correct amount up front covers the lot. And a pay once store forever model takes the worry out from having to maintain the data you stored and it becomes more like I stored my data on my hard drive and don’t have to pay rental for the data on my harddrive. But its even better than owning your harddrive because it survives longer than a harddrive.

And of course the cost to store that image you upload is going to be very very small, in terms of micropayments. Some estimate it will be around the cost of storing an image on a many TB drive. 1/4000000 of the cost of the $200 drive. Like 0.005 cents. And this cost will reduce year by year.

This assumes those farmers who farmed back then are still around to get the 1/4s 1/8s

The farming reward algorithm in effect does this already. Just does it in an averaged way and pays up front. If the farmer continues then they get more rewards as they serve up data

This also saves on complexity and “smart contracts” etc


#274

Ok thanks for explaining a bit. I was quite bewildered to see some responses so far actually from the community. From my perspective it was simply bringing up a potential problem. If someone thinks it’s not a problem, simply defeat all my arguments there is no need to start calling me trolling etc…

Well, another way is you can ask people to pay 10% upfront for initial costs then 1% every month. Still will be preferred over only giving one option to pay 100% and store forever by some people I’m sure.


#275

Another thing is and this is basically my argument anyway. Which is well what about all the costs of bandwidth ongoing? So the cost of bandwidth ongoing is not a huge concern but the initial cost is? You can also say the initial cost is then outweighed by all the recurring payments that’s gonna come in later. So farmer may initially suffer a little. But then benefit more as time goes on.

With the current model. Farmers initially benefit a lot. But as the network is free to browse and farmers have to pay to give bandwidth to people overtime. They may not benefit. So actually thinking about it, these two complement each other very very well!


#276

No I meant it as

  • today it might cost (all inclusive cost) x amount to incrementally handle one chunk
  • Next year it is likely (averaging every farmer obviously) to be 1/2 x
  • year after 1/4 x

Now the 1/2 might be 40% of x or 60% of x and vary slightly from year to year. And next year or two might see a 10 times reduction in the cost of SSD storage, so sometimes the reduction could even be much greater.

Now I didn’t include the statistic that says for an average file that as it gets older it is accessed a lot less year by year. Now this isn’t for OS files but files people store. Think of those dvd movies you or someone you know has bought. The first 3 months you might watch it a few times, then the next 9 months you watch it again less than you did in the first 3 months. Then the second year you watch it a lot less if at all.

The point being that averaged across all chunks the older the chunk is the much less its read. This impacts bandwidth in a way that sees new data consuming most of the usually free bandwidth costs. So even for those who pay incrementally for bandwidth those cost dramatically reduce for a particular chunk over time.

So if most farmers due to economics are on unlimited (or extremely high quotas) and their bandwidth cost is insignificant or zero and only a few are paying incrementally then dramatically reducing the very small overall bandwidth cost for a chunk over time is extremely important. Important in the sense that rental needs to charge 80% of the normal cost up front just to cover the the statistically shown usage of the upload for bandwidth portion of the costs. In other words its just not worth the effort and the complexity of a rental system.

Also if you look at industry and the consumer rental system for electrical/electronics, you see that the actual rental charged ends up so much more than paying up front. And due to the complexity of introducing rental into the code will cause a lot more processing and bandwidth and disk activity that the actual cost to store rental data could even be twice the cost of pay once data. Pay once sees disk activity to just store and whenever its retrieved. Rental sees daily checks if the data is to expire (daily disk activity for each chunk) and bandwidth usage for every node in the section to agree on whether to delete or not.

The point is that rental has its overheads that must be charged to the renter. For the computer industry it is like 40% break even then rental firm charges a profit on top. I think from a guesstimate that the network would have to be charging something similar for the first couple of years.

Rental is a can of worms (coding, user experience, costs) that really makes it a cure that is worse than the perceived problem.

I honestly think you way overestimate this cost. By a lot.

Anyhow farmers are paid to retrieve data so that covers those costs even if they are small (or zero for most)


#277

Well depends on how you code it. It can check monthly too. I don’t know how long it takes to program but I think it’s good to have an option where you pay less upfront but ongoing. It’s similar to phone plans. A lot of people choose them over paying 100% upfront. So yeah… And remember there will be people paying upfront too. So basically the resources and initial cost needed by the people who choose rental will be complemented by people who pay upfront for forever data…that’s what I mean by they compliment each other very nicely. Then overtime recurring fee will help the network expand faster than simply relying on new data being stored.

So basically, now you have BOTH the existing stored data AND newly stored data returning coins to the network hence paying the farmers as opposed to only newly stored data.


#278

That means some people would get 59 days rental instead of 30. Remember you are making every single chunk stored on the network subject to this rental. Every MD subject to this rental. What of the xyz tokens worth hundreds of dollars I sent you but you were unaware till I reminded you. But by the time I reminded you those tokens were deleted because you never paid the rent.

It is such a can of worms, the examples of problems caused by rental is huge. Every APP that stores MDs for you has to be paid rental, what of all the business cases where data is lost because the rental was missed (due to some misconceptions or glitch)

We then need companies to explain it to people, businesses and where they are liable to pay rent or the customer is liable to pay rent.

What of the last will & testament that isn’t discovered till the personal papers are found detailing that the will is now stored on the SAFE network. But oh wait it was 31 days and it was deleted because no one knew rental was required.


#279

You’re assuming it’s a rental model now… It’s not. It’s still pay once for forever data. The rental model is simply an add on to give people additional option. When they store they have to clearly choose it. And If they choose that then they should be able to handle the consequences of it.

Also with the time frame it can be for one year. So 10% for one year isn’t bad. And an extra 10% for first time initial storage cost.


#280

Why do we have to discuss this now and try to change original concept? Simply give people option to delete their data, if they want. That is what people need, control of their own data, whether private or public(yes even public, if I am the only uploader). The rest is simple, if all time storage costs are too high, than it will solve itself by increasing put price. Since there is a function which increase put price if there is lack of storage and increase mining rewards, market will handle that. Than we will see if price is too high for PUT, if yes, than what can prevent Maid team to implement temporary storage as addition to permanent? So, let first the market show if this complication is required, and if yes, than solution can be added later. Creating complex solutions in front is almost always wrong. In my experience everytime people expect something to happen it is usually wrong, people are wrong almost all the time. Let’s keep things as simple as possible and just keep options to improve it later if experience shows that it is required.


#281

For the user that already is possible, just remove the datamap link from your list (directory) of files. That is an effective way of deleting. If the file is private then no one can access the file ever.


#282

Not continually (emphasis is mine). In my proposal, this is done only when a section is about to run out of space, which should never happen according to your reasoning about exponential growth.


#283

How about quantum computers? If I can’t delete my data, only datamap to them, than once there will be quantum computer able to break the cryptography all data would be easy to decrypt. As far as I know Safenet cryptography is not secured against very large quantum computers. So sooner or later those data will be endangered. Or am I missing something?


#284

Without the data map, how do you know which chunks to decrypt?


#285

If I have a file with less than 1 MB, in how many chunks will it be stored? I expect that it will be in 1 chunk only, since chunks have 1 MB max size. Let me know if I am wrong. If I have a super powerful quantum computer, than I can decrypt every chunk, and than all files with capacity lower than 1 MB are decrypted. But maybe I do not understand the process correctly.