Editable data and rewarded deleting

[to7m]

I reckon there should be a reward for deleting data.

The network could become mostly junk data in the next few decades. Imagine a billion always-on HD dashcams uploading their video feeds to the network automatically. That alone would fill it with junk. If there’s even a tiny reward for deleting old and obsolete mutable data, then it would provide manufacturers with an incentive to automatically delete this data after a while.

So, maybe a refund of 50% the equivalent current put cost? That would be easy for a user to understand. Then updating mutable data would cost half as much as creating more data. It could make the difference between the network being 99% junk data and not being 99% junk data. Which in turn would make put prices in the deep future 99% cheaper. Even a 10% refund would achieve the same long-term result.

[jlpell]

@neo

So for my $20 I get 30 million dollars.

Yeah neo! Hopefully you would share some with me for my efforts…
All joking aside, yes, I see your point. I’m not necessarily convinced that it would be that bad due to the coupling with external fiat markets… however I do agree that direct conversion to safecoin by the network is a double edged sword and to be on the ‘safe’ side you are correct that it’s not worth the security risk to implement/code it that way.

@neo

Thats why I suggested elsewhere that the person deleting the file gets like 1 put refund for 3 chunks (a file is at least 3), 2 puts refunded for up to 10 chunks and say 1 put refund for every 100 chunks after that.

It seems much more fair to given the back PUTs 1:1, but I can see that this leaves open an attack vector where an adversary could repeatedly PUT and FREE in a loop to waste bandwidth. So the next most simple thing to add hysteresis would be a 2:1 ratio (free 2 to get back 1), but this hits the user pretty hard and I think you want to incentivise recycling, dare I say “composting”, as much as possible. This would lead me to a 10:9, 100:99, 1000:999 ratio etc. The effect of this has a few implications assuming the network itself only allows for a one-way conversion of safecoin to PUTs:

1. A secondary safecoin market would emerge for “used PUTs” as @dyamanaka has mentioned in the past . This price would naturally be lower than the going PUT rate offered by the network, so human buyers always benefit over spot PUT price. In some cases, the human recyclers also greatly benefit because under severe network events they might get a better price in safecoin than they originally paid for the PUTs as that free-market run completely by humans would determine. This would be an outlet for PUT speculation and can only benefit the network and users.

2. The attack vector enabled by allowing for PUT composting is most simply controlled by modifying the recycling ratio. Having a ratio that is more refined, such as 10000:9500 requires the user to delete data in larger blocks in order to see a benefit. Whereas changing the actual ratio returned determines how readily a good user is willing to throw away garbage as well as how quickly an adversary would see their attack resources diminish.

A fixed ratio of 100:99 is probably most simple, intuitive, and beneficial to a well-meaning user since it comes down to losing a unit percent, and it makes them more comfortable with interacting with the network since novices would have the feeling they could ‘undo’ a temp upload and not be penalized greatly. However this also gives the adversary a lot of iterations before their attack is diminished by a large amount (0.99^100 = 0.36 ). For an attacker the network security perspective wants to present them with 100:0. While a fixed ratio is easier to code, a variable ratio set by the network would probably be ideal. I think your reward tiers described above speaks to this. Having an even more flexible algorithm would give the network complete control over whether PUT recycling was even necessary. I know the network doesn’t keep ‘time’, but it would be nice if the algorithm could be tailored or proven to show that well meaning users would nearly always receive a 100:100 or 100:99 ratio, whereas any sort of network abuse would quickly push the recycling ratio to 100:0. Perhaps this could be based on the rate of other network churn events and info related to data chains.

@neo

I think his idea of recording a (throwaway style) of ID for the uploader in meta data for the chunk and the user supplies that ID to delete their entry in meta data (and delete chunk when all gone) could work. But I’d still say it has to be marked as deletable so that APPs / people know it can be removed.

Agreed.

@neo

I’d also go away from storing temp in a “special” directory style of thing and just have it as an attribute of the file.

Yes, I was thinking of file attribute also. The folder idea was basically from a UI perspective. If a user marks a folder (which is also a kind of file) with the “tmp” attribute, then any files uploaded under that folder are automatically given tmp attributes as well. I’m thinking this is a sapp level thing (safe app), but it might be worth having it in the safe NFS library. Right now I can’t think of a case why you would want a temp folder or directory, but have non-temp files inside.

@neo

But still I have to be convinced that the rate of increase of single disk drives and the increased rate of production of disk drives will not exceed the need for any deletion.

True. At the very least I think the feature protects against a “public relations” attack vector. Most people feel good when they can find ways to be thrifty. ‘Recycling’ is seen as virtue in most parts of the world. “Waste makes want.” It also provides another tool in the toolkit for SAFE to adapt and protect itself, but in a philosophically SAFE way, ie. “Safe Cannibalism” (For network data of course! ). Apoptosis is an important function in the morphology of living things, as opposed to necrosis.

@neo

And then if MDs can do the function of temporary files then do we need deletable immutable data? That might solve it all.

True again. But having some non-zero cost ratio (> 100:99) will still need to be required otherwise couldn’t some adversary just loop continuously over MD creation and deletion in some type of ddos attack? After thinking about it a bit, I would suppose that “deletable immutable data” is not logically self-consistent… but since it is only “temporary immutable data” we are talking about, then it is logically consistent to allow it to be deleted/mutated back to free space. However, “temporary immutable” might be more easily achieved via an access permission placed on an MD, which is then removed if the user decides to make it fully mutable, or the MD automatically copied/moved by the network to an ImD if the user decides to make it fully immutable.