Using new (modified) MData to Model Safecoin

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.

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

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

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

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

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

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

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.

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.

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.

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

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

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());

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.

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

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

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

Been suggested a number of times in the other forum.

The main drawback of that is the transaction load. When you get to microSAFE or nanoSAFE and someone only has the payments for farming rewards that are nano (maybe micro) SAFE MDs. Say after a time they served up 100 million GETs and has 100 million times 7 x 1 nanoSAFE. Now they want to pay for an item that costs 1/2 of a SAFEcoin. The network does 500 million transactions to transfer the amount.

There are simpler ways that would reduce that to one 2 transactions.

1 Like

Nano divisions may be overkill. Even micro divisions. I was thinking that the smallest denomination is milli: 0.001 safecoins. And the largest denomination is 100 or 1,000 or something like that.

The automatic exchange service is very efficient since it just burns coins and replaces them with new coins of other denominations.

And transactions between wallets become very efficient. For example if Alice wants to send 4,500.75 safecoins to Bob, then that’s only 21 MutableData objects to transfer: 41000 + 5100 + 70.1 + 50.01.

The plan has always been for micro transactions to be possible in the future. You mentioned earlier that planning for the future is important. And you are correct so micro is definitely needed and nano gets close to paying for each GET no matter the conditions.

But when its possible to do a sub-safecoin worth of transfer/payment with 1 to 3 transactions depending if a coin needs to be divided then that has to be so much better than the potential of many hundreds of transactions if the person only has 0.001 of a safecoin MDs

And the sub coin amounts can be much lower than nano (1/10^9), it is very easy to have 1/10^18 as the smallest amount. And no extra load if transfer/payment is 0.0000000000003476374 or 0.1

Also instead of the potential after a few years of having half (or more) of the coins as 0.1, 0.01, 0.001 safecoin MDs. you only use the wallet’s MD with a network updated division amount. That means no extra MD’s for division whereas having MDs for 0.1, 0.01, 0.001 denominations could mean anywhere from 1 to 1000 times the safecoins generated in extra MDs

BUT only if she has those denominations, or she has to ask the network to convert all of her sub coin MDs into those values first. This involves transactions per MD being combined. If the network rewards to her had been 100 thousand 0.001 denominations then there has to have been 100 thousand additional transactions to recombine them into higher denominations.

tl;dr
Simply put,

  • it is not necessary for separate denominations to divide safecoin
  • separate denominations is very wasteful on MD storage
  • separate denominations dramatically increases transaction load when payment includes sub safecoin amounts (MDs)
  • Storing divided coin amount in wallet MD is not affected on how the coins are divided whereas denominations can involve from 1 MD up to 1000 * amount to be transferred (actual number is dependent on the users current holdings.
1 Like