RFC 57: Safecoin Revised

[neo]

@JoeSmithJr

Not as much as denying it as a possibility, what would the point be? Suddenly, there would be a need to store a bitmap for no other reasons than something that could be done much easier in another way, just as you described later on. Coins as network objects was a great idea, I love it, but there’s no point to retrofit its remnants into a fundamentally different concept.

Which is why I moved onto the progression of the idea and removed the need for a bitmap

EDIT: and I agree there is no need for the notion of the previous implementation. Maybe we could go to the max of u64 and have 18,446,744,073,709,551,616 nanos == just over 18,446,744,073 coins and then issue 4,294,967,296 nanos (approx 4.3 coins) per MAID. No inflation and no loss for anyone. But increases total supply for the future and allows @anon86652309 to realise full use of all bits. Only downside is people’s perception of imaginary inflation.

@JoeSmithJr

If we had nanos, there may be no need for probabilistic rewards even. They would be a useful fallback for when safecoins are expensive though.

The idea though was to account for coin scarcity in the section to be used for payment. So as more is issued the %age of the amount determined paid is slashed by that %age.

So if the reward payment is determined to be 22 milli safecoin then

• 10% issued already then payment is 19800 micro safecoin
• 50% issued already then payment is 11 milli safecoin
• 90% issued already then payment is 2 milli safecoin
• 99% already issued then payment is 220 micro safecoin

So as the issued coin approaches the 2^32 safecoin then actual payment is reduced more and more from the calculated reward amount. In the end almost impossible to ever issue all coins.

[JoeSmithJr]

I know: “… just as you described later on”

I was just referring to a recurring theme in this thread in general.

[Mendrit]

@neo

lower limit. The 2^-63 lower limit was not going to be good since a reasonable amount of free space meant near zero cost to PUT and near zero farming rewards

It is not going to happen to reach near zero cost, because price of SafeCoin would rise to xxx (also farmers rewards) and uploaders would use benefit of cheap PUT for sure. It is more easy to upload 100PB than increase available space by 800PB.

[neo]

@Mendrit

It is not going to happen to reach near zero cost,

The old algorithm allowed this whenever spare space was over the amount of used space.

Yes it would get used quickly, but it still would exist. Lets say early on people are adding 2 to to 4 TB each vault and there are 80,000 vaults. So that is about 30PB and so would need 15PB stored before it rose above that 2^-63 safecoin put PUT

It will take time to upload 15PB and remember that PUTs are used for a lot more than straight 1MB chunks. Messaging, updating ADs, creating accounts, which are way less than 1MB

The low price affects more than just storage

BUT in saying all that I agree that the 2^-63 will not happen that often, but early on it is real easy in comparison to later on.

[digipl]

Maybe these two post can help. We both reach the same conclusions in different ways.

Safecoin VS SAFE Storage

I am thinking the possibility of using the notion of velocity of money to achieve the desired economic stability of the network. In the general theory the velocity of money is set as: [image] when [image] is the velocity of money for all transactions in a given time frame; [image] is the aggregate real value of transactions in a given time frame; [image] is the price level; and [image] is the total nominal amount of money in circulation on average in the economy (see “Money supply” for d…

Early demand, and effect on storage costs, after launch

I appreciate the difficulty that comes with designing these aspects of the network, but I think the NC variable (the total number of client accounts) is a bad one in this formula: StoreCost = FR * NC / GROUP_SIZE Compare a scenario where X amount of clients each consume on average Y amount of resources per day, with a scenaro where 5*X amount of clients each consume on average Y/5 amount of resources per day. The resource usage is the same in both scenario’s, but the StoreCost is 5 times highe…

[TylerAbeoJordan]

Is there any plan for sections to share information generally and specifically regarding total puts and existing storage?

I guess that such info sharing might be useful, but also becomes an attack vector. As would re-balancing safecoin holdings between sections. So I’m guessing this info would not be available.

If it is sharable though, then perhaps this info could be useful for modifying farm payouts.

[mav]

I think the proposed farm reward (FR) algorithm in RFC-0057 is quite useful as a starting point.

FR = 2*SC

FR is split between all farmers (weighted by age) and devs/producers etc. I’m only going to discuss the total FR here, but the changes would keep the split mechanism in place.

The change that might make this more sustainable would be to replace 2 with a dynamic multiplier. It would be very similar to the idea of Farm Rate but to avoid overloading the term I’m calling this the Health Multiplier (HM).

The formula would become

FR = HM*SC

where

HM = 2/(4^FC) and FC is percent of farmed coins between 0 and 1.

So to expand it fully out,

FR = 2/(4^FC) * (1/G+F/N)

which makes the reward depend on a) total farmed coins and b) portion of full vaults.

For 0% of coins farmed, HM = 2, ie same as the current RFC-0057 proposal.
For 50% of coins farmed, HM = 1
For 100% of coins farmed, HM = 0.5

For 10% of coins issued (eg network start with ICO allocated) HM = 1.74
For 90% of coins issued (eg a lot of uploading has happened suddenly) HM = 0.57

HM = 1 means that FR=SC, ie the reward mechanism acts as a direct transfer from uploaders to farmers with no bonus or reduction from the network.

HM = 0.5 means that farmers only get half the upload fee, the other half is kept by the network for future use.

It’s worth clarifying my perspective: safecoin is primarily a tool for manipulation. It’s meant to encourage or discourage certain behaviours by uploaders and resource providers depending on the condition of the network. The purpose of the manipulation is to optimise network health and minimise wasted resources.

I use the fairly hostile word ‘manipulate’ because the network is an entity that’s going to need to defend itself from malicious behaviour, and the coin is the main tool it uses to protect itself.

The maximum potential for manipulation is when 50% of coins are issued. More than that reduces the remaining coins to encourage new farmers, and less than that reduces the supply of coins for uploaders to use. So my feeling is the network should be aiming toward 50% supply with some considerable elasticity during periods of extreme activity. HM*SC should hopefully achieve that.

It’s still a very rough idea but it’s a small step in a certain direction. A lot of words for what is really a fairly simple idea of changing constant 2 into a variable.

I think the disallow rules for new joining nodes would need some further consideration. And so would the StoreCost algorithm since I think it’s probably too restrictive in RFC-0057. Interested to hear any thoughts about the Health Multiplier idea.

---

@Toivo

How about getting rid of the term “coin”?

This is (imo) inevitable but I feel you’re starting the conversation many months too soon! I’m happy to see this comment though!!

[neo]

@mav

For 100% of coins farmed, HM = 0.5

This means that the either the total coins will exceed the 2^32
OR
The network will continue to the total coins existing then Stop. The slow down does not match the required slow down due to coins existing

@mav

means that farmers only get half the upload fee

They should be disconnected at the point of reducing payment due to %age of coins existing.

The farming reward need the capacity to follow a different algorithm to upload fee to allow for the forever storing requiring say 3 times the farming reward instead of 1.5 or 2 or 2.5

But the most important thing is that farming rewards scale down towards zero as the existing coins approach 100%, otherwise you will realistically get to the point where farmers start getting nothing because no coins exist and it becomes hand to mouth economy

[mav]

@neo

For 100% of coins farmed, HM = 0.5

This means that the either the total coins will exceed the 2^32
OR
The network will continue to the total coins existing then Stop. The slow down does not match the required slow down due to coins existing

Yes this same thing applies to RFC-0057 with constant 2 instead of HM. I wasn’t trying to fix it, just take one step further. Not sure what the step after this one looks like yet, any ideas?

[oetyng]

@TylerAbeoJordan

Is there any plan for sections to share information generally and specifically regarding total puts and existing storage?

The sections will communicate, and there is a notion of trusted section, so that destination section can prove validity of source section, by proof chain provided in messages.

A general health status, including the numbers you mention, could be pinged.

@neo

But the most important thing is that farming rewards scale down towards zero as the existing coins approach 100%

Was going to say this as well.

@neo

Maybe we could go to the max of u64 and have 18,446,744,073,709,551,616 nanos == just over 18,446,744,073 coins and then issue 4,294,967,296 nanos (approx 4.3 coins) per MAID. No inflation and no loss for anyone. But increases total supply for the future and allows @Fraser to realise full use of all bits. Only downside is people’s perception of imaginary inflation.

I’d definitely be for this.
Regarding people’s misconception: thwart it immediately by always stating loud and clear that it absolutely NOT is inflation. After a certain time it will be known, and also overplayed.

@JoeSmithJr

If we had nanos, there may be no need for probabilistic rewards even. They would be a useful fallback for when safecoins are expensive though.

Exactly, the nanos enable continuously rewarding, maybe even for every rewardable action (although buffered up at the Elders until large enough for payout, to minimise traffic).
Probabilistic would not be needed until there isn’t always at least one nanosafe for every rewardable action. Up till that point, a function approaching to zero does the job.

@Toivo

How about getting rid of the term “coin”?

I thought about this as well. But it has sort of transcended itself. Like ‘Telegram’. When I hear that now, I don’t think of really old times anymore, I think of this tech company providing me with encrypted chat, and it feels very modern. Until a split second later I realize this and chuckle.

[neo]

@oetyng

Exactly, the nanos enable continuously rewarding, maybe even for every rewardable action (although buffered up at the Elders until large enough for payout, to minimise traffic).

I am pretty much assuming that this will be the case before launch. And as you say there will have to be a buffer or counter or accumulator that is kept and the vault is paid when there is enough to make it worth the effort/cost of a coinBalance Update.

[zeroflaw]

@neo

But the most important thing is that farming rewards scale down towards zero

I’m not sure this is because the existing coins approach 100%, but more because the “cost” to store 1MB will trend towards 0. Which is why I feel Safecoin needs a built in mechanism to be infinitely divisible. So a kind of “halving” event where the api moves from payments in micro to nano, nano to pico. This is to keep both spamming down (what is considered worthless now in 10 years = lunch), but also a human element, nobody wants to see number than 3 decimal places, let’s be honest. 21,214.745 ( is way more readable than) 21,214.745825354264573645836354, especially when everything after 3 decimal points is considered worthless.

@mav

The maximum potential for manipulation is when 50% of coins are issued

I like this idea of 50%, it gives the network plenty of “Safecoin” it can use as rewards during disasters to protect itself and incentive more farmers.

I know storing data “for infinity and beyond” is a key part of the network, but what about garbage? it seems wasteful, could data have a lifespan of 200 years, unless copied?

---

Also I understand the idea of using u64 and nanos now, that requires a way to stop spamming at the beginning of the network due to worthless dust. and later on as storage space continues to get cheaper, would be small enough. I think both of these problems need to be designed into the coin from the start.

[oetyng]

Yup, it’s mentioned in the RFC IIRC.

[neo]

@zeroflaw

I’m not sure this is because the existing coins approach 100%, but more because the “cost” to store 1MB will trend towards 0.

No most definitely because existing coins approach 100%. There is absolutely no reason to assume the cost to store 1MB will be anywhere close enough to zero to make farming rewards become near zero because of that fact alone

@zeroflaw

but also a human element, nobody wants to see number than 3 decimal places, let’s be honest. 21,214.745 ( is way more readable than) 21,214.745825354264573645836354, especially when everything after 3 decimal points is considered worthless.

This is up to the UI to display the balance the way you personally want to see it.

[zeroflaw]

[neo]

And still no guarantee that it will continue.

For most things we can assume it will and be confident. BUT for the case of price algorithm we cannot be so bold. It might flatten out next year or speed up further.

The reason to make the farming rate to go to zero as the %age of existing coins approaches 2^32 is to ensure all coins are never in existence. Not due to storage costs. The PUT costs is not changed due to this adjustment of Farming rewards due to existing coins %age

The fiat exchanges will cater for that with the market reactions to actual storage prices.

[zeroflaw]

Storing data forever, in my mind is only possible if storing data forever gets cheaper.

If the issue of coins is always targeted at a 50% issuance. When technology fails to keep up with demand (more storage every year for 100$), the rewards will continue causing a increase in Safecoin supply to 70%, incentivising newer technology to be developed so people to profit from the Safecoin rewards. As the technology outstrips demand, the coins in supply will burn away and supply will be back to 50%.

Also as time progresses what 1 entire Safecoin will buy, will equal more and more space. As more and more data by the average user increases. Which is why I feel Safecoin needs to be infinitely divisible.

Which also makes math sense to me. Paying for 1GB of PUTs now costs 10 Safecoin, but in 10 years only costs 0.1 Safecoin and in 100 years only 0.0000000000000000001 Safecoin. Thats how the network gets to promise to store something forever right? it’s like a “Futures contract” but the network knows it can honour the storage because it will cost less in the future, and you’ve paid significantly more than you would in the future.

So to always be able to cost less in the future, we need a Safecoin that’s infinitely divisible, right?

[TylerAbeoJordan]

@mav

Yes this same thing applies to RFC-0057 with constant 2 instead of HM . I wasn’t trying to fix it, just take one step further. Not sure what the step after this one looks like yet, any ideas?

Not sure how to simplify this, but sort of a natural log kinda thing:

=((1+(1/1-FC))^(1-FC))-1

This variant is simpler and gives a really hard drop:

=(1-FC)^e

Both give you a decay from 1 to 0 as FC goes to 100%.

@mav – I’ve added yours into the sheet too:

= 2/(4^FC)

Edit: play with it on google sheets! – add more

Farming Rate Calc

Yeah, I’m bored …

[mav]

@neo

This means that the either the total coins will exceed the 2^32
OR
The network will continue to the total coins existing then Stop. The slow down does not match the required slow down due to coins existing

Just wanted to clarify something here.

There are three pots of money involved in the existing rfc-0057 farming reward algorithm hardcoded to 2*SC

Uploader pot which pays storecost and ends up with farmers
Network pot which pays bonus and ends up with farmers
Farmers pot receiving safecoin from above two mechanisms

This can be summarised as U+N→F; ie uploader and network goes to farmer.

Eventually the Network pot will be empty since it never gets refilled by this process. U and F are able to be interchanged / refill each other but N just depletes itself.

The Health Multiplier changes this.

When HM>1 the N pot is depleted. U+N→F
When HM=1 the N pot stays the same. U→F
When HM<1 the N pot is refilled. U→F+N

Just wanted to clarify this difference between how the two mechanisms would work.

[Toivo]

@oetyng

I thought about this as well. But it has sort of transcended itself. Like ‘Telegram’. When I hear that now, I don’t think of really old times anymore, I think of this tech company providing me with encrypted chat, and it feels very modern. Until a split second later I realize this and chuckle.

I actually came to same conclusion right after posting. Coins in digital context are already a thing of their own and not so much tied to the coins of material world.

And maybe the common coin of PARSEC is so deep in the basement of the backend, that it doesn’t interfere too much? Or is there possibly situations, when we would like to call some Safecoins common coins, like shared with ID’s / accounts or such?