"Micro" PUT proposal

Care to explain “PUTs are actually free” since that means in normal comprehension actually free. If you meant earn some safecoin to be able to pay for the PUTs then its not actually free. It would be effectively free.

Actually free PUTs will invite the spammers back and give them a way to spam the network to bring it down from the start.

1 Like

if you think that you dont need to buy safecoin then PUTs are free! you have a vault → you get safecoin automaticly → you can use those on PUTs

But that is not Actually free. and to say actually free is a true deceptive misrepresentation of effectively free.

2 Likes

Ok ok, I understand your view of actually free. But I mean it in a way that you dont need to work a job to get safecoin to PUT, you only need to run a vault to your already running pc

2 Likes

On dWeb blog I put it like this:

On SAFE Network your data is secure and stored for as long as you want for a single one-time upload fee paid to the network itself. You can even barter spare disk space in exchange for storage by becoming a ‘farmer’ who contributes resources to the network in exchange for credit to purchase SAFE storage.

Like @neo I think it is misleading to use the word free here because it will mislead people.

2 Likes

What about a data type that expires unless a condition is met?

New person opens up Safenet UI, signs up to an account (1 PUT with a 24hr expiry?). If the user now provides resources to the network, and is a good actor, the debt is paid and the account is made permanent. (While the account still needs to pay its debt, this should be made clear to the user with red banners and warnings etc.).

To stop spamming:
1 expiry PUT per IP address
global limit of 10 million active debt puts (10TB)

Now the barrier to entry to the network is gone, and the exposure to spamming is limited. Nothing stops a bad actor from using up the 10 million account signup limit, but it won’t hurt the network, just make signing up more difficult for real actors.
Even with the above resource limits, that could be throttled to around 10 signups a second?

3 Likes

There are no IP addrs on the SN. One of the fundamentals is anonymity.

New person opens up Safenet UI, signs up to an account (1 PUT with a 24hr expiry?).

That would be shitty UX if your account would “just” vanish “without any indication”. Also what’s the purpose of that account if there’s nothing else you could do on the network without SCs?

If your point is that there is no way to create a SC account without SCs to even start farming:

Receiving a CoinTransfer is a single PARSEC vote to increase a CoinBalance 's value. Once the vote is returned by PARSEC having reached consensus, the Elders try to credit the indicated CoinBalance . If it doesn’t exist, the source balance will be refunded by sending a new CoinTransfer back to the source for the same amount.

https://github.com/maidsafe/rfcs/blob/master/text/0057-safecoin-revised/0057-safecoin-revised.md

Then we need to just change this into: create a SC account when the first farming reward gets processed.

1 Like

Everyone has an IP address. As far as I’m aware, farming uses IP address to determine vault uniqueness.

Like I said in my post it would come with warnings, and be made very clear to the user what is happening. The idea is this gives a “free” way to bootstrap account creation.

The alternative is faucets controlled by maidsafe, which can still be abused and used for spam. At least with an expiring account the network can cleanup spam.

The network doesn’t use time, so any durations would have to be at client level… so gameable I’d have thought.

We are still talking about a negative balance there though right? So if you multiply that my millions of spam accounts, then we have an attack vector, amirite?

2 Likes

Is an attack vector with limits, its controllable and the effects are short lived. Some would say this is the cost of convenience.

A section can agree on a timestamp of creation of a PUT?

I don’t think the time question is an issue as another time related method can be used to limit duration (eg counting concensus blocks).

If the attack can be limited (eg to a maximum loan balance per section) this scheme or something along these lines might be feasible, because I think the benefit of the attack could be quite limited:

  • gaining a small amount of time limited storage per fake account
  • slowing growth by throttling the free onboarding mechanism, but only if you can overwhelm the network/section loan balance, and only for the duration you can keep this up

There’s also a fixed cost to the network in funding the loan, whether or not the borrowers are legit.

It sounds to me like the attack would be expensive to maintain and of very little benefit.

So it might be worth investigating if we think it has significant benefit to growth through easier onboarding.

My guess is that it’s too complicated to get all the support pieces into the existing architecture to be worth trying to implement. But it would be a good exercise for someone in the community to look at how this could be implemented, and what that would involve. And who knows, maybe it can be done.

But first I think an analysis of the benefits to onboarding is needed in combination with estimates of feasible loan balances for different network sizes and growth patterns.

4 Likes

It does sound like it would be a stretch to get this kinda thing up and running for Fleming, however, it could probably retrofit nicely into some of the UX proposals we are working on…

e.g. you ask a vault to generate an account invite for you. Existing infrastructure means this takes a little time… this kind of approach makes it near instant, but the flow remains the same.

5 Likes

I’ve often thought it would be neat to have a “self-destructing” datatype. The data would be valid for a certain number of network consensus events and then be deleted.

Another interesting one would be a data chunk that gets deleted after the first GET is made for it.

While it is interesting to consider, I don’t think it is a good idea with respect to the goal of the OP.

I think this is a brilliant idea as well.

I’m not sure why people have such an aversion to ‘Time’ on the network. It seems like a powerful and simple concept to myself. The network already has a consensus algorithm, (were all happy it will decide the fate of our precious safe coins), yet deciding what time it is can’t possibly be allowed?

In reality it is a consensus algorithm and therefore should be able to derive consensus on anything!?

How I think the concept on expiring data would work.

Vault X: (periodically checks a meta tags on chucks held in their vault)
Vault X: (finds a chuck that has expired)

Vault X: Sends a message to section, the time is now 1571902717, chuck with hash ba7816bf8f01 has expired at 1571902715.

Vault A,B,C,D,E…: Agree on the consensus that the time is greater than 1571902715, and execute a delete instruction.

For use once data, a similar process can be implemented with signed delivery reports from the client, which trigger the delete process.

Personally I just think it’s cool that the network doesn’t require ‘time’ in the general sense.

This kind of timed deleting could be usefull in certain scenarios though, assuming the speed of consensus doesn’t change too much with network load / timezones and other factors.

It just won’t be usefull if it’s there’s a chance its taking 100 times longer, or shorter to remove a chunk, instead of 1 day it may take 100 days, or 14 minutes with no way to tell of what it’ll actually be.

And what to do when someone else uploads the same chunk? does it still get deleted on time or is it now deleted with the new one?

It could still work though, if the consensus speed is static enough, when dealing with private(deletable) data, and I didn’t miss anything important.

NO to Rental. Its been discussed and time based deletion because you miss a deadline has been examined and found flawed.

We’ve been told that we have a delete data type when people want to use that. But there are many reasons that these rental deadlines can be missed and to have web sites disappear because a person passes away is what SAFE is trying to prevent. Sites like educational ones that people put up once and no updating needed. A lot of electronic tables for instance.

A perpetual network is not a perpetual network if data/files/sites disappear because people stop updating that and miss rental deadlines.

2 Likes

So if I accidentally check in a private key or secret into a perpetual web project, I have no way of deleting that information? (Obviously I would need to revoke and key rotate), still I should be able to clean up a mistake.

If we can’t delete what about a time-based redaction. Information is hidden for 100 years?

Time would require a central server to provide an agreed reference. It would also add a great deal of complexity to the code (this was discussed somewhere but I can’t find the relevant thread). There are proxies to time that can be used instead such as number of iterations of a loop or something like that, and Parsec ascribes an order to events on the network.

You don’t need a central server at all. Every machine on the planet has a built in clock. All you have to do is agree consensus of Time.Now() using parsec.

3 Likes

The feasibility of using Parsec to reach distributed consensus on time is worth exploring even though the core Safe Network protocol will not require it. Higher level time stamping services will require it and unless a decentralised API can be presented to developers they will turn to integrating with centralised solutions. Depending on how critical the higher level service this may undermine Safe Network autonomy.

3 Likes