Using new (modified) MData to Model Safecoin

General
,
1

Following up on the proposed changes for the Mutable Data RFC. One such use case is an application of the third use case is safecoin divisibility. This brings many features to safecoins:

  • Payments are not forced to be rounded to multiples of whole safecoins and can use fractions of a safecoin.

  • Concept of put balance can be suppressed because fractions of a safecoin can be recycled.

  • Farming attempts are not a whole or nothing matter anymore: if the selected random address is the address of an existing safecoin then the farmer gets the fractions that have been recycled (though sometimes there can be none).

  • A safecoin can play the role of a wallet by itself. To be useful as a wallet its value must be higher than 10 cents. Many here hope that its value will explode one day, but let’s be realistic: there are potentially 4 billion safecoins and 21 million bitcoins. That means that even if Safecoin market cap reaches Bitcoin one’s then one safecoin would be worth 900*21/4000 = $4.70, that not enough for a wallet. To increase Safecoin value, a possibility brought by divisibility is to reduce the number of potential safecoins and correlatively to exchange one Maidsafecoin for less than one safecoin.

Let’s take a numerical example to illustrate these features. For simplicity I take here an u8 pair as key instead of an u64 pair. Imagine also that the put cost is seven 256th of a safecoin.

  • User A farms a whole safecoin, the generated safecoin has then one key: (0, 255) belonging to A.

  • A wants to pay thirty-one 256th of safecoin to user B. First, A makes a division and generates 2 keys (0, 30) and (31, 255). Then A transfers ownership of the former to B.

  • A wants to add a new file in an existing directory. Its size is more than 3072 bytes but less than 3 MB so the cost is three puts. A division of his/her remaining fraction is done that replaces (31, 255) with (31, 37), (38, 44), (45, 51) and (52, 255). The first three are then recycled (deleted). A only owns (52, 255) now.

  • User C farms the same safecoin. He/she only gets the recycled fraction, which is (31, 51).

  • User D farms the same safecoin. He/she gets nothing because no fractions have been recycled since the last farming of this safecoin.

At the end of these operations: A owns (52, 255), B owns (0, 30) and C owns (31, 51).

Another possibility (optional): The lottery (probability of triggering a farming attempt) can also be replaced by farming of a safecoin fraction. This provides more regular revenues to farmers and avoids creation of farming pools like in the Bitcoin network. Both can also be used simultaneously (a lottery to farm a fraction of a safecoin).

2 Likes
2

I thought of that when I read your post BUT the problem I see is that when the case of all coins are divided as would happen when paying farming that way, then there is only enough divisions that can fit in a MB of data. Paying farming would exceed that so quickly its not funny.

Also you need a coin in order to divide it. Who owns the coin?

I still feel that another MD tag type is needed for divided coin which holds the amount of divided coin in the particular wallet. (yes the wallet address is the balance holding MD address too) When a coin is divided it is frozen by the network. About Easter this year I suggested that system and still seems the best way so far.

1 Like
3

I meant a safecoin can be used as a poor man’s wallet needing no other development than the one I propose for safecoins.

Then I don’t quite understand what you mean by “paying farming”?

If it is a user recycling a fraction of safecoin to pay for a put, then the count of values before and after the payment is the same. The temporary splits can be avoided by shortening directly an existing key: in my example intermediate keys (31, 37), (38, 44) and (45, 51) could be removed and existing key (31, 255) could be shortened to (52, 255), possibly in 3 steps because the user buys 3 puts => no limit is exceeded (value must be re-signed, but that doesn’t change its size)

If it is the network paying a reward to the farmer, then no division occurs at this time:

  • Either a brand new safecoin is created with one value (with key (0, max(u64)) => no limit is exceeded

  • Or a new value is added to an existing safecoin. In that case this insertion might sometimes fail because a MD limit is reached => this is not worse than what was planned (a farmer got always nothing when attempted address was an existing safecoin).

About “who owns a safecoin?”:

A safecoin is a MD with a reserved tag (7 was the Maidsafe plan) and a DivisibleOwnership variant (in my proposal). Users own parts of safecoins, these parts are the values of the MD. Initially when an address is farmed for the first time, the lucky farmer (A) will own a part that corresponds to a whole safecoin. Each time A pays someone else or put some files in the network, A’s part will shrink. If A pays someone else (B) a division occurs and ownership of new part is transferred to B.

After several divisions a MD limit can be reached that prevents further payments with division. But payments without division are still possible from this MD, meaning ownership transfer of existing values, which is still better than transferring a whole safecoin. Divisibility allows finer grained payments but there is still a limit and this limit is a compromise between performance and number of values in a MD to be defined by Maidsafe team.

Furthermore values constantly shrink and then disappear with PUT operations, so at one time divisibility will be possible again for this MD.

Creating fees for divisions with a price increasing with the number of existing values in the MD can be an incentive to avoid this situation (with a double effect: people become reluctant to split values and more values are recycled).

Another possible mitigation is possible on the client side: when a farmer receives a whole safecoin (and so the fee is still low) he/she can split it in various denominations to avoid later division problems.

1 Like
4

Paying farming as in when a GET is done the farmer is paid the 0.001 or 0.00001 or 0.0000000001 or even less of a SAFEcoin

It will not take long before there is realistically 10’s or millions of thousands of splits of a coin. You cannot store that many keys in one safecoin. Which is why I never considered it a potential solution to division. Yes it would have been possible with SDs as it is with the new features in MDs

The same will occur after some time with ordinary transactions between people. The number of divisions will most likely increase more often than recombinations. To recombine you need the transaction to involve a coin the receiver already has a division of.

Thus doing a separate MD for holding division balance is simpler and cleaner.

5

I agree there are issues this idea, such as:

To recombine you need the transaction to involve a coin the receiver already has a division of.

But they bear further analysis. For example, the network will very often be the receiver and so once splits are present in most coins, any payment to the network for storage is likely to result in a recombination.

So I’d like to see some analysis of this idea so we can make a comparison with the alternatives. I pinged @dyamanaka yesterday to see if he’s still around, in case he’s interested.

I think the are quite a few effects to be considered, some technical, such as mentioned in this topic, others may be psychological, such as people ascribing higher value to coins that have not been split at all, or which still have many splits available etc. Fascinating!

1 Like
6

Yes but then the opposite occurs and yet another/many farmer is paid using that coin/MD so yet another/many division

The system represents only one entity. Every time that coin/MD is used to purchase/transfer a portion of a coin then there is another division created unless the receiver ( 1 of many 10/100s of millions in the future) is part of that coin.

To use the system as a potential source of a solution does not take into account the millions and we hope billion or so people with one or more accounts there will be. Using the coin to hold its divisions will only work for the test/alpha/beta systems when we have less than 10,000 people. And even then the MD may be over flowed with divisions.

Simply take a coin that is used for payments (rewards or transfers/payments) and realise that for this method to be effectual it needs to allow for use as part coin payments to a significant portion of the people/accounts in the network. You cannot rely on every coin being divided either as that is also short sighted and demands that all coins to be eventually divided when there are not enough divisions in coins to pay every farmer, which we hope will be in the 100’s of millions.

One MD can only have around 4000 divisions max if each key is simply the account ID and value. But I’m sure a division will need more than 256 bytes (1/4KB = 1/4000 of an MD)

So once a coin has been used to pay 4000 different farmers it cannot be divided further so the “system” may be left with 9/10ths of a coin it can do nothing with once it pays each farmer 1/40000th of a coin for each GET done. It could be 1/40000000000th to each farmer too which is worse.

The idea is great sounding and I thought of it too early on. But the scale of the network and the shear number of accounts & farmers will swamp any holding of the divisions in each coin.

We cannot juggle coins around to give divisions when needed and especially a person cannot grab someone elses coin in order to divide it when they need to because all of their “safecoin” is in SafeCoin/MDs that are fully divided. (when they try to send something smaller than any of the divisions in the MDs to someone in a similar situation)

Imagine the work the system needs to do if all my “wealth” is in 1 million Safecoins but only 1/100000th of a safecoin in eacg and I want to send 10 coins. Thats 1 million transactions. And it only gets worse as the divisions increase.

2 Likes
7

Good thoughts, :slight_smile: though I don’t entirely agree with all of them. For example, once a coin can no longer be further divided it isn’t necessarily “stuck”, the network can still use the entire fraction it owns to reward a lucky farmer, though the farmer will find it less valuable (less easy to use efficiently) than a fraction of a coin that can still be subdivided.

We can try to imagine how the presence of “sole owner”, “mixed owner” and “full” coins might affect the network and human participants. Everyone will want some fragments of coins that can still split, but the only way to ensure that is to hold the whole of a coin, hence a premium. But as soon as you pay a fraction of that coin, what’s left is at risk of becoming undplittable! So he part of shared coins becomes a risk if your fraction has significant value, less so if your fraction is tiny. So lots of complex incentives!

So I think this is actually very complex and to early to rule out on the basis of these points. Of course, the complexity itself may be a negative :wink: In general I’m thinking it isn’t the best solution, but I don’t understand the implications well enough yet to decide.

BTW I said analysis when really I meant modeling, although further analysis is also useful as you have shown.

1 Like
8

How? If you award a “lucky farmer” the whole fraction then you create an unbalanced gamable system but to remain fair then how can it be done? the system has 9/10ths of a coin’s worth (for instance) and the farmer needs to be paid 1/10000th of a coin? So how can it. That MD is stuck until someone’s share is reduced to zero.

Also for that coin any use of it has to use the full amount of the share since there can be no more division.

If a user has only that one share in their whole account then they cannot pay anyone unless that person also has a share in that coin.

To rule out the use of this as a suitable coin division mechanism I only have to identify one major issue, and this is more than a major issue, its a show stopper. Yes it might be worked around but any such work around that I can come up with has just as many problems elsewhere.

But I identified many issues.

Any modeling is preceded by a number of thought experiments in order to formulate the model. If the thought experiments show major failure before you even model then no use modeling.

The fact that coins can be stuck with the system owning a large portion that it cannot give out in rewards is one. Two is the situation where a person has only one share in a maxed out (division wise) coin they cannot pay/transfer an amount smaller than their share unless that person has also a share in that one coin is also a show stopper. Yes external exchanges may solve some of it, but introduces greater problems for the system, fees, complexity in core code, and so on because the system has to be able to “exchange” through the external exchange.

tl;dr

The thought experiment shows that it is unworkable because of the VERY limited divisibility. Even if you could increase that to very large amounts then you could, but in doing so there will be times when the system is doing many thousands of transactions just to transfer a few coins worth of divisions.

For modeling you have show that coins will not be filled up with divisions over the days/months/years of operation. Otherwise actual modeling past thought experiments will just get stuck on fully divided coins. Most likely around 256 to 1000 divisions.

####There are simpler and so much more efficient ways to divide than using a very limited method like this.

EDIT: I have not even talked about the recycling problem. A coin can only be recycled when all shares are removed and only the system has 100% share. Have a serious think about how many coins will be completely owned by the system when 4000 people have shares in the coin and are randomly trading in those coins. If and only if the majority >80% of the coin use is to pay for PUTs will you see a significant number of coins become completely owned by the system. BUT if as we hope the coin becomes a major unit of trade then paying for PUTs will not realistically reach that tipping point and there will always be an increasing number of coins being fully divided.

1 Like
9

I don’t think this problem is a show stopper because a non divisible fraction is still spendable to third parties (as a whole) or usable for put payments (by parts). It is like saying a bank note is a show stopper because it cannot be divided. And frankly we are talking about fractions of a safecoin that is currently valued 10 cents.

But if it is, then my proposal can be amended by limiting the possible factors for a division. Let us imagine for example that the maximum number of values in a MD is 256, then the vaults could control that a whole safecoin can only be divided in parts multiple of 1/16 safecoins and that such part can only be divided in sub parts multiple of 1/256 safecoins.

That way the lowest non divisible denomination is the same for everyone (1/256 safecoins).

3 Likes
10

We disagree, I don’t see this as a show stopper at this stage. At the moment, farmers are rewarded in whole Safecoin, so I don’t understand why you think rewards based on different sized fractions are clearly not going to work. It seems obvious to me that they could, but…

I’m not going into trying to design this, I don’t want to spend my time doing that.

1 Like
11

While that is true I think you will find the problem is 2 fold. 1) The network creates new coins(divisions) and as such the source of these fully divided coins is from rewards. I do not think rewards for each GET will be typically 1/256th (or even 1/1000th) of a coin, so then fully divided coins initially come from the system retaining relatively large divisions of each MD that has to be created. 2) If we have a coin fully divided due to users trading then we have to wait and wait for one of the larger divisions to be drawn down. But it has to be fully drawn down OR partly drawn to another who has a division in that particular coin. And if 256 or 1000 divisions then that is actually unlikely when we expect many many millions of people using safecoin.

Or 1000 divisions would be easy

Limiting it to this would be great for SAFEcents or SAFEmillicents. The only issue is the same as separate SAFEcoins MDs idea. The volume of transactions would greatly increase.

But for the future where we want Micro-SAFEcoin or Nano-SAFEcoin I doubt it could work because of the size of a MD and the shear volume of transactions the network has to do just to send some coin’s worth.

Actually for Ander’s coin this would be a great idea, since (s)he wants to be able to divide his/her coin by 100.

12

My (it’s he) initial idea was to have different denominations such as 1, 10, 100 and so on. But it becomes too inefficient when coins have to be split and joined. So now I only have coins of denomination 1, like safecoins without divisions.

13

It says in RFC 47: “tag: u64”

I think 64 bits is a too small tag. When I want to create a new data type I don’t want to have to worry about my tag clashing with another tag on the SAFE network. If the tag instead is at least 256 bits then it’s possible to easily create new tag types that are unique.

14

2^64 is about 2 X 10^19

Or 18,000,000,000,000,000,000

Allocating one random ID per minute, it would take 34,000 years before the odds of a clash fell below 1 in 2 X 10^9.

So is this really a worry?

Another concern is ensuring a sufficiently random generator, and avoiding number ranges and values that are likely to be favoured by humans choosing manually. Those will be issues no matter how many bits are used.

2 Likes
15

Consider the exponential progress of information technology that Ray Kurzweil and others have described, with Internet of Things (IoT) devices getting smaller and smaller, each with its unique tag type(s). And artificial intelligence software creating huge amounts of new tags on the fly.

Vint Cerf said that when they made the IPv4 specification he thought that the address space was more than would be needed. And Bill Gates allegedly said that nobody will ever need a computer with more than 640 KB of RAM.

2 Likes
16

In the beginning of the SAFE network u64 will of course be more than plenty enough. I was more thinking long term and using a 256 bit hash of some piece of text plus a few random numbers will be a convenient way of creating a new tag type that most likely will remain unique even in the future. Like:

tagType = SHA256(“roposed Russian diplomatic retaliation follows a tweet from the Russian embassy in the US, promi” + Math.random() +date.millis());

17

I think that can be handled with system updates. Considering that each new ID requires a program to be written for it, I think one per minute for 34,000 years (or ten per minute for 3,400, or 100 per minute for 340) leaves plenty of room. There’s also headroom in the odds I chose, so plenty of time to figure out if we need a bigger ID space. I don’t know 100%, but looking at those numbers I don’t think it is a problem.

18

But wouldn’t that kind of system update be like trying to replace IPv4 with IPv6, metaphorically speaking? (I’m just thinking about the possibility of the SAFE network becoming huge, absolutely enormous in the future.)

2 Likes
19

Actually it would be a lot simpler than that.It would require just a little more complexity in the SAFE code. The new version code could be written to handle MDs with tag of 2^64 and tags of 2^128 (or 2^256).

The 2^64 tags simply take up a 2^64 range in the larger range. Probably the first 2^64 tags.

It should even be possible to “upgrade” the previously stored MDs as they are moved because a vault is turned off. It also would not be a problem if some copies of a MD had the “version 1” tag size and some had the larger size

6 Likes
20

For divisions of safecoins, simply allow MutableData objects to be worth different denominations such as 0.001, 0.01, 0.1, 1, 10, 100 safecoins. And add an automatic exchange service as a core SAFE network functionality.

A wallet with for example 1420.34 safecoins then contains fourteen 100, two 10, three 0.1 and four 0.01 MutableData objects.

The automatic exchange burns MutableData objects (makes them unusable) and directly issues new MutableData objects without farming. Such as converting ten 0.1 to one 1 object. Or one 100 into ten 10 objects.

1 Like