RFC: Safecoin Implementation

Ah…got it. Read it too fast and got excited I think! But I like the qualification that it can only be used for storage.

Probably in the RFC - but are these transferrable?

More importantly though, I’m concerned that there’s no roll back proposed for this. If it’s only in test-safecoin, then that makes more sense, but I feel that a proposal this ambitious should have a concrete end-game in mind.

I don’t know if this has been suggested and discarded; and it’s not relevant to bootstrapping (the real Safenet), but what about the possibility of having/running a separate testing-only fork of Safenet? This could be used to test out all new features/fixes in advance and giving away free coins wouldn’t be an issue as they’d only work on the test-net, not the real official stable network.

1 Like

Well, the incentive seems to be to get content on the “official stable network” so this does the trick well enough.

1 Like

Nope. Thats why its in equivalent storage amount and not coins. Imagine the scripts running to create 1000’s of accounts to get 50 coins each :smile:

The RFC is still being written.

When safe-coin is introduced it will be TEST-SAFECOIN. After it has been through a few updates and it is working correctly then there won’t be a restart and the network will be deemed live. And in the quote it even says that the 50 coin worth of storage may not be given when the system goes live.

3 Likes

Love this community. Thanks guys!

1 Like

Here’s an idea for consideration…

Bootstrapping Solution

  • 0% to 20% capacity, 0 SC buys unlimited PUTS.
  • 21% to 89% capacity, 1 SC buys X PUTS.
  • 90% to 100% capacity, PUT unavailable.

Bullet Point #1
This threshold creates a zero barrier to entry as long as there is abundant storage available. Users are free to upload as much as they want without Safecoin, until the Network hits 21% capacity. This solves the chicken/egg bootstrap problem. It also eliminates the need to create multiple accounts.

Bullet Point #2
This threshold goes into effect and adjusts PUT costs based on the supply/demand formula… whatever it may be.

Bullet Point #3
This threshold goes into effect and stops PUTS. It keeps 10% of storage available to compensate for a churn event that has more farmers leaving than joining. There are other safeguards in place to prevent data loss. This is just my way of preparing for worst case scenario.

The percentages are just examples used to illustrate how this could work. If storage really does become abundant, then everyone will be able to upload for free. But if storage fills up, then SC will be required. This network can bootstrap itself without pre-existing SC.

6 Likes

Interesting idea, I would be surprised if someone didn’t try it out (if not the safenetwork team then a fork) thumbs up.

1 Like

If someone has few GBs to post publicly, they could chunk it smaller chunks and pay people to post it for 40 Safecoin each. The only inconvenience is having to build a small “concatenate” browser add-on to stitch the chunks together after download.

1 Like

It is unlikely that it will be used when the network goes live. Its only a “bootstrap” feature for testing and when system goes live it will no longer be required. It might be as it goes live or in the first update to the live system[quote=“neo, post:48, topic:5826”]
And in the quote it even says that the 50 coin worth of storage may not be given when the system goes live.
[/quote]

1 Like

What’s important is whether data so uploaded will remain or not. It appears it will (otherwise the bootstrapping wouldn’t work). So in any case it could pay to create a few million accounts just in case.

We don’t know in advance which test system will have its data remain and system goes live

There will be a few tests done and resets are done between them. Obviously minor changes might not have the reset done. But how many projects work first time :smile:

Feel free and create those accounts after each reset. The PUT costs according to the RFC will be very small while the network storage is mostly empty

I won’t necessarily create any, just saying the cost of creating an account is zero, while the benefit is larger than zero.

You can create 100 accounts but are you going to use a different account for every few files you want to upload?

If I have a large backup archive I may be interested in the possibility of using a “drop here” script that breaks it into X-parted encrypted Zip, creates X accounts, uploads the chunks to public shares owned by those accounts and outputs a HTML page with all the links for Down It All type of download later.
This was discussed countless times before, so I’m not explaining nothing new of course, just saying the old abuse scenario is back.

Yes during testing. No one knows which is the last test network. All data will be dropped between tests.

The attack vector is still there but only for each test. The free allocation of PUT resources will not be a part of the live network. So good luck creating all those accounts and uploading all that data each time the reset occurs and never knowing if it will survive.

So while you are correct, it is mostly contained in test networks, and is actually a good test for the network.

But what’s the point of bootstrapping with giveaways when no test data makes it to the mainnet? Why not simply have a web form with a captcha and whoever passes it, show him auth details to a new account and send him 50 test Safecoins? It’s be less open to manipulation and it wouldn’t be necessary to run this through an RFC.

If any of the test data will survive to the main network, then it will be exploitable. If not, why is necessary and worth the extra procedures and coding?

1 Like

You don’t know why. Surely you understand the need for testing and why you cannot rely on data produced from a flawed storage system to be carried across between tests. Bootstrapping is to allow testing obviously. But you knew this already!

Similar attack vector. When money is involved captcha passing scripts are worth it. So when the last test turns into live those testsafecoins are deemed to be safecoins and thus an attack vector for free coins. THAT IS why it is an equivalent amount of storage which is not transferable and will not continue into the live system.

It is more open to manipulation when you give a trade object that is worth real money for the last test system which becomes the live system. Any captcha system has its hacks and even if it cost 5 coins to break each one, its well worth it.[quote=“janitor, post:60, topic:5826”]
If any of the test data will survive to the main network, then it will be exploitable. If not, why is necessary and worth the extra procedures and coding?
[/quote]
There will be exploitable parts to SAFE or any other system for that matter. The trick is to weigh up the efforts taken to exploit and the returns for the exploitation. It seems that @dirvine or the devs have decided that it is an acceptable risk. How many times will the exploiter have to reupload the same data when each test starts??? Will the exploiter be sure that the test system will not go live only hours or a day before declared live and the update to cancel the freebies occur almost immediately.

By the same logic the almost free uploading when there is plenty of free data space is exploitable. Its designed that way. Plenty of free space and for 1 coin you will get the BD rip uploaded, if you are quick enough before the space starts filling up again.

Also if the system is being exploited to an unacceptable amount then its a minutes effort to take out/change that line of code that gives the free space on account creation and restart the network with a blank slate and go live (relying on presale coins for bootstrapping).

So I am at a loss to see your problem with a measured measure of free data upload to bootstrap the test systems.

Since this credit is for PUTs, how might that affect messaging?

“SAFE Network, free XGB of message storage space per account.” I quite like that.

If the idea is to allow farmer boostrapping, then it’s sure that some testnet data will make it to mainnet.

Yes, but with (for example) a captcha that is known to work makes the extent of exploits smaller compared to completely open access to anyone.

It’d make freeloading more costly, but it’s also going to be costly for “honest” testers who may need to re-upload their data every time the network is reset.

Well that will happen no matter if there is a free upload amount given or not

Still possible and more so if money is involved so that is why [quote=“neo, post:61, topic:5826”]
THAT IS why it is an equivalent amount of storage which is not transferable and will not continue into the live system.
[/quote]
And [quote=“neo, post:61, topic:5826”]
Also if the system is being exploited to an unacceptable amount then its a minutes effort to take out/change that line of code that gives the free space on account creation and restart the network with a blank slate and go live (relying on presale coins for bootstrapping).
[/quote]