Safecoin divisibility

Development
1

In the deflationary discussion @jreighley mentioned concerns about the divisibility of Safecoin

I will first put a short disclaimer: the past few months have been a relentless focus on the SAFE network, and Safecoin considerations are a consequence of the SAFE network, as illustrated by the work on StructuredData. So opinions expressed here are purely my own, although hopefully largely in sync with the community. It seems though there is some uncertainty on how Safecoins can be divided, should you want to do (extreme) micropayments, or if they Safecoin (being deflationary) increases in value.

I just want to shed a bit of light on how I understand these questions, but the final resolutions will be made by the whole community through the RFC process that is gaining speed.

So a Safecoin is a StructuredData signed by its owners, and the integrity protected by the network. It is like a physical coin, an informational object that you can claim possession of, or transfer to other owner(s).

In order to put information to the network your ClientManagers will charge you safecoin in order to authorise your request. However, if for every put, small or big, the network would have to transfer or divide safecoins, it is similar to how a 1 euro coin cut in two does not make two 50 cent coins (as you would need both pieces to examine very carefully that they did fit together as an authentic 1 euro coin. More so, subsequential division of coins, would eventually leave you with grains of metal that are unverifiable (even if they were authentic).

So what do we do instead? before you can put data to the network as a client (identified by your public signing key), you need to create an account with your ClientManagers. You do this by sending the deletion of a safecoin, which is “returning that safecoin to the network for renewed farming”; you’re declaring the abandonment of ownership of that safecoin. Your ClientManagers in return will create and hold an account for your Client(public key). This recycle of a coin to the network has transformed an indivisible informational object, your safecoin, into a double precision float* account in your ClientManager group. Now that you have an account with value, a put request will be successful if the ClientManagers can deduct your account for the size of the data.

So the total value you own on the network is the sum of the account on your client(s) + the safecoins that are owned by you. Notice some interesting differences

  1. safecoin is an informational object; your account is a numeric value
  2. safecoin can also be co-owned, multi-sig, escrow, …; your account is single client owned
  3. your safecoin holdings are not query-able and distributed; your account balance we can either make publicly query able, or requiring a signed request - up for debate

So now we have transfer of ownership of safecoin; and we can transfer account balances (currently not considered yet); we can even allow mixed combinations: transferring a fraction of a safecoin, returning the coin to the network, and splitting the value over account balances.

Should the value of a safecoin become too high, then as mentioned several times, we, as a community, will have time to implement a second coin of fixed smaller denomination - as we want to avoid that farming becomes bitcoin like, low chance of gaining a coin, but massive payout on being rewarded. That would force farmers to join forces to spread the investment risks. We can learn from Bitcoin and not repeat those evolutions.

*note: “a double precision float” is obviously not how it will be implemented. Either an existing numeric type with a set accuracy should already exist in rust, or we will have to create one. Rest assured we will not implement your money with a dp float.

29 Likes
2

Ben is on theloose tonight :slight_smile: quality content.

Account transfer sorts divisibility issue brilliantly. Could I convert my acc balance back to safecoin?

3

You can sum several safecoin to have bigger account?
This can be the beginning of the idea of a “wallet” account instead of a set of single coin?

2 Likes
4

He made some huge changes in routing that simplified it a lot, so got to breath a wee bit there :slight_smile: we will all be back soon to add some ideas at the upper layers. It’s great to see so much done without us lot, whilst we are away on our own self created hell, but we have escaped now (nearly). So expect more :wink:

11 Likes
5

No you can’t (at least I would not see how, or why we would allow for it) to reverse the flow (i.e. from account to safecoin). One reason would be it would create an internal market, allowing arbitrage within the network to exchange coins to accounts and back; effectively forcing the 1-to-1 conversion to be broken by market forces - I think.

2 Likes
6

yes, but the transfer happens within the same client. A safecoin owned by client a will charge account for client a; so if you would have multiple clients, best to transfer coins from a to b (or later transfer account balances from a to b - if we would allow that)

7

The market would exist on the app level I guess. What would be a lowest denomination of an acc balance?

8

Thanks. This is wonderful!!!

3 Likes
9

You want to eliminate representational errors, so a floating point representation is not good. It needs to be fixed radix. I imagine a unsigned 32 integer should suffice for the integer part of your balance, allowing you to own all but one safecoin on the network, i.e. 4294967296 - 1 safecoin; then your question really refers to how many bits do we reserve for the fraction of your balance. Here we have to make a choice whether to work with a binary division or stick conventionally to a decimal division.

I assume that the same amount of bits reserved for the fraction, i.e. 32 bits is a good balance. I personally think using a binary interpretation is the most sensible: defining the value of the fraction bits in relation to the integer bits as x/2^32, which would allow atomic micro transfers of 0,000.000.000.232.83 safecoin. It also allows your account to hold at max 4.294.967.295,999.999.999.767.17 safecoin, or 99,999.999.999.767.17% of all safecoin :smile:

So for most humans it would be considered that 0,000.000.001 is approximately the decimal accuracy of a micro payment, or one billionth of a safecoin (if we go for 32 bits for the fraction - I don’t see why not)

5 Likes
10

30 bits is 1073741824 or close enough to a billion when we humans think of such small payments. Only as the payment gets higher does the extra 7.37% become significant

I would thus suggest that 30 bits is better for mere mortals than 32 bits.

3 Likes
11

So how does one keep track of his holding if he cannot find out what he has? (after a year I won’t remember which coin IDs are mine or not 32bit IDs are hard to remember)

12

I just realised something I had not realised before. This cycle between safecoin and account balance effectively introduces inflation and liquidity into the system. While safecoin itself is deflationary, and people might want to hold on to it for increase of value, when you burn the safecoin into your account, the safecoin is available for farming again, but the value in your account is not necessarily spent. This effectively increases the supply of money in the system, causing inflation.

If however everyone would hoard their account balances nothing new on the network can happen, so farming indirectly is reduced as well. This is crying out for differential equations to model the behaviour now. Anyone interested?

5 Likes
13

yeah, but I only think in 1, 8, 32, 64, 256 or 512 bits :slight_smile:

14

Farming would continue until all coins are released and hoarded, or until all data being used is cached

Groups that store data in real time would likely spend first to make sure they can store that data, and then try to acquire more coin later. I sense that this will occur on a high rate. So inflationary concept drives forward.

15

Farming would continue until all coins are released and hoarded, or until all data being used is cached

yes, but I only want to watch the same youtube video some many times. Eventually I want new content, and that requires balance to put. So that is another indirect influence on the farming rate; users don’t want to get all the content on the network, they want to get the new content on the network

can you elaborate? Are you talking about network groups or groups of people?

2 Likes
16

Would the system only allow upto one SAFEcoin’s worth to be in their balance.

It would be a case of 2^32 SAFEcoins used/available and upto another 2^32 worth of SAFEcoin, so the inflationary effect is not really there because it will always be in flux between the min/max value worth in SAFEcoin terms.

And if you allowed transfer of balance then when the balance is over one SAFEcoin’s worth the person cannot increase it by spending SAFEcoin. Yes I know someone could spend a SAFEcoin in 10 accounts and transfer to the one, but this is counterproductive since they can only use the balance in the network.

17

My interest/hobby apart from all things digital machines is embedded systems and recently named as IoT (internet of things) and one thing I dearly love seeing is the talk of signed messaging. In other words I can have one device running SAFE that needs to communicate with another device and SAFE would allow the two devices to KNOW the messages are legit even though the message has passed through a 3rd party network (the internet)

Now I would hope that SAFE would allow the automatic spending of a SAFEcoin (with appropriate limits to safeguard errant IoT devices) so that the messaging can continue without the app needing to check the balance each time.

1 Like
18

that is a good question, and I think that is a reasonable upper limit, but as realised afterwards; there is no limit on the total amount of value in the system, as their is no limit on the amount of clients (well there is, it’s 2^256…); so no practical limit.

Putting a lower bound on an account balance is probably useful to not have a massive loss of value if you loose your credentials, but not very relevant as you can always create multiple accounts to spread the total value.

19

One suggestion - likely to cause initial objections :smile: - is to make the account balance perishable… forcing people to not burn too many safecoins, and spend an account balance rather than hoarding

20

That really has been there for a long time. Because we were told that spending a SAFEcoin gave us X amount of resource use. This discussion has shown a way of managing this in a quantitative way