RFC 57: Safecoin Revised

That’s a bit fringe to turn into a fundamental network feature.

1 Like

Yes and another is a major one in that if we go back to PUT balance then it becomes a gamable feature.

Big holder of safecoin monitors the PUT price and buys up tons of PUTs (multiple accounts if needed) while the price is really low and since buying PUTs does not affect space (only change in free space does) they can spend all their coins.

Then when the price jumps up real high due to space running out they can “sell” their PUTs and profit off SAFE. SAFE’s goal is to give lowest price possible but this ability to transfer PUTs allows that to be bypassed

And another major damaging factor for SAFE would be the ability to buy real cheap then hammer the network when space is low.

Put balances should not be transferable, it is not a fringe issue (that example was maybe fringe), it bypasses SAFE’s goal to provide the lowest price possible at the time.

Although @Toivo’s example would be a way for a company to handle the companies adhoc storage costs or maybe even most of it.

6 Likes

I think a simple safecoin allocation for puts is enough – a separate safecoin variable that cannot exceed your safecoin balance. You could also use this to allocate a fixed percentage - a nice feature.

So you don’t purchase in advance, yet you can allocate and cap for future purchases - thus giving you control over your ‘putting’. This takes away the gamefication but still gives users flexibility and control.

4 Likes

This is a great point and a strong argument for buying resource directly with SAFECoin (or equiv. to).

If people want to get cheap storage, they can still try to get maximum SAFECoin for their money. That is an external market instead of an internal one, which seems more sensible.

Edit: more importantly, it is one instead of two markets. Much easier to model and manage.

2 Likes

The original non transferable PUT balance was fine because you could only buy the balance (1 coin == full 2^64 balance) then the put cost at the time was subtracted from that balance.

This meant

  • could not hoard PUT balance
  • could not make a market of balances
  • one account had a max of 1 safecoin divided into 2^64 balance value
  • the balance is not the # of puts but the one safecoin divided into 2^64 parts and the cost of a put was subtracted from it
    • if PUT cost was 2^62 then you got 4 PUTs from that balance
    • the PUT cost could change a lot and the appropriate amount subtracted from the balance
    • so you were not buying PUTs but just having a coin divided into 2^64 parts and the PUT costs taken from that each time.
6 Likes

Thought this might fit here :joy:

12 Likes

The problem is that u128 is not well supported by compilers. It should be a set of four 32 bit unsigned integers…128 bit just like divisibility of ipv6.

Why not just go crazy and do 8 unsigned ints (insignificant to total user storage). This allows each wallet balance to work in divs or decs depending on the user’s preference. Bankers can do decimal, philosopher geeks get to have fun with binary. This also satisfies the original statements made at crowdsale that there would never be more than 2^32 SC and each would be divisible to at least 2^32.

1 Like

If we do get rid of PUTs and use micro/nano safecoin deductions, i’d like to control my spending and still ring fence safcecoins as a PUT balance.
In this way, if my “PUT balance” still has safecoins, I could sell them.

2 Likes

Rust has official support for 128 bit ints, thus it is generating all the plumbing for you on architectures that do not support 128 bit ints. Just as it does with 64bit ints on systems that aren’t able to do 64 bit math.

edit: rusts support for different platforms: Redirecting...

9 Likes

Nice. Rust! However, there might be future bugs in rusty plumbing. IMO it would be beneficial to have a low level dedicated/minimalist safecoin add and subtract library.

1 Like

You mean for other langs? Or do you think, that you can make a 3. party 128bit int math package for rust, that has higher code quality that rust itself? For rust this should be already handled by the NanoCoin, MilliCoin, … types

1 Like

In any case making a simple 128 bit add/subtract routine is easy.

3 Likes

No. 20 chars…

3 Likes

Some more ideas, both are similar but different way of conceptualising

Pressure Release Valve

The network operates smoothly under ‘normal’ variability but changes behaviour under stress conditions. I think this sudden ‘valve’ style change in network behaviour is not great but it does lead to consideration of what counts as dangerous stress. It also might encourage less sudden changes in client behaviour if clients know their changes might make their experience worse.

Queue

The network processes requests during busy times based on some queue mechanism, like bitcoin does with the transaction fee. In bitcoin the transaction fee is used to put a queue of transactions in some order or priority, and during times of stress when the queue is very long the network can still function predictably.

In SAFE maybe the queue is ordered by the type of event (vault join vs GET request vs vault relocate vs PUT request vs split event vs hop message relay etc) but there may be other factors that contribute to when and why events are processed. What could the network do when the queue gets very long?

7 Likes

This is my attempt at working out the longest/shortest time to issue all coins for RFC-0057.

Longest time will be when the StoreCost is smallest, thus reward is also smallest.

Smallest StoreCost is 0.005 (see this post for calcs/reasons)

New safecoins issued for each put will be 0.005. The total reward is 0.01 which consists of 0.005 existing coins paying for the PUT and 0.005 new coins for the farm reward.

So total reward events possible (ie puts) is 2^32 / 0.005

Using a suitable put rate we can see how long it takes to complete the total reward events.

A ‘low load’ might be simulated with the normal ongoing load. Average phone storage is 64 GB and average lifetime of 2 years; let’s say it gets full after 1 year… this means about 64 GB PUTs per year. (There’s a ‘heavy’ load used later in the shortest time calc).

Assume every put is exactly 1 MB.

This has a put rate of 180 puts/day/user (64*1024/365)

The number of users might be the number of users on this forum, which is about 9000 (from the about page of the forum).

So the total put rate is 1,615,956 puts/day (9000*(64*1024/365))

This gives us 531,569 days (2^32/0.005)/(9000*(64*1024/365)) or 1456 years to fully deplete the rewards.

Shortest time

Largest StoreCost is 0.51 which will result in the biggest reward and fastest rate of coin depletion.

Total puts possible is 2^32 / 0.51

initial load: average 100 GB per user in the first month (from this topic)

Assume 30 days in a month.

This gives a put rate of 3413 puts/day/user (100*1024/30)

Let’s keep 9000 users

So total put rate is 30,720,000 puts/day (9000*(100*1024/30))

And time to fully deplete all rewards is 274 days (2^32/0.51)/(9000*(100*1024/30))

Summary

Key parameters are:

Upload rate (maybe puts per user per day, maybe total puts per day, I don’t know the easiest unit here)

StoreCost (maybe derived from % full vaults)

These two parameters allow us to calculate the total time to issue all coins for RFC-0057.

For 9000 users uploading between 64 GB per year and 100 GB per month the time to deplete is between 274 days and 1456 years.

But let’s not forget that after all coins are rewarded farmers still get paid the PUT fees so farming always has some reward so long as PUTs are being done.

Any thoughts?

2 Likes

Which is why I’ve always been a fan of farming in gets. Even if uploads are slow coming, as long as people are active in the network (using your resources) you will be paid. I think it will produce better mid term results. Help new farmers weather any luls in uptake on the network. People always want to consume. They don’t always want to post. Or rather, many more consume than post.

2 Likes

I also prefer to farm in gets since it preserves the value of ‘the data is stored’ rather than ‘the data was stored’.

But I want to clarify I feel there are two issues being merged here: whether new coins can be fully depleted vs what actions lead to rewards.

My post was really trying to get at whether new coins can/should be fully depleted (like bitcoin) or whether new coins should be always available and never fully depleted (ethereum is never fully depleted but that’s because there’s no cap, anyone know of a coin that’s capped but also never fully depleted?)

5 Likes

I vote solidly in favor of capped but not fully depleted. Using a health modifier as @mav proposed before. I’ve tinkered with it some and this is my fav version:

2(1-FC)^e

The red line is mav’s original modifier, the blue is my proposed modifier. It gives a nice even rate of change as supply goes down. This will drive the price higher naturally with no bumps but supply will never run out even though capped. This is a linear graph so it appears to go to zero, but on a log scale graph you would see that it never reaches zero.

I don’t know of any - which would give Safecoin another unique quality over other coins - a plus for marketing and those who are looking for a non-inflationary coin.

6 Likes

From RFC : “We also update the terminology of both of these RFCs and substitute ClientManager, DataManager and CoinManger with Elder.”

Will Elders have different personas? A single elder operating as all three personas within the same section… Seems like this would be a security problem???

1 Like

It would be better just to prolong the Mav’s one to zero. He have HM=1 at 50% which looks better.
Actually it could be linear straight from HM 2 at 0% to HM 0 at 100%.
Original Mav post

2 Likes