Using new (modified) MData to Model Safecoin

General
,
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
21

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
22

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.

23

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
24

The idea is that wallets automatically convert coins in the background to optimize so that a low number of MDs are maintained. Yes, if let’s say that a thousand 0.001 coins have been farmed then 100 + 10 + 1 automatic exchanges are done by the wallet to convert the coins into one safecoin of denomination 1.

But the transactions between wallets, which is important from an end user perspective, are very efficient with denominations.

EDIT: In practice the automatic conversion done by the wallets is gradual for farming. For example if 19 0.001 coins have been farmed then the wallet can convert 10 of those coins into one 0.01 coin. And when the wallet has nineteen 0.01 coins then ten of those are converted into one 0.1 coin and so on.

25

Yes, and that requires transactions for each and every reward payment. So 100 million reward payments EACH requires 2 additional transactions to take and combine the 0.001 reward with something bigger. Or if you like 11 additional transactions to combine each 10 into one. 10 transactions to “burn” the 0.001 amounts and one to combine. This is occurring for every ten rewards. Its a massive overhead for the network when its simply not needed, especially when it can be just the transaction to pay the reward without the additional transactions to combine MDs.

So the potential is there for up to 1000 times the transaction load for just milli-safecoins as the minimum

You cannot get away from the additional transaction load having separate MDs for various denominations.[quote=“Anders, post:24, topic:398”]
Yes, if let’s say that a thousand 0.001 coins have been farmed then 100 + 10 + 1 automatic exchanges are done by the wallet to convert the coins into one safecoin of denomination 1
[/quote]

NO its 11 transactions per 10 0.001 payments. Each 10 x 0.001 reward payments made requires combining to 0.01 Then each 10 0.01 need 11 transactions to combine to 0.1 then 11 transactions are needed to combine 10 0.1 to 1.0

So 1000 reward payments of 0.001 requires ADDITIONAL (at a minimum)

  • 11 * 100 for the recombination to 0.01 MDs
  • 11 * 10 for the recombination to 0.1 MDs
  • 11 for the recombination to 1.0
  • total of at least 1221 additional transactions to do that recombination of 1000 x 0.001 rewards to 1 safecoin.

But that is not the total. It took 1000 transactions to do the reward payments, so 2221 transactions (at least) to get you one safecoin from 1000 reward payments of 0.001

Whereas using the method suggested last easter there is the 1000 transactions for the reward payments and 1 final transaction for the conversion of the balance (which reached the value of a coin) back into a coin.

Of course denominations goes nowhere near solving how to do micro transactions. And people want nano as the minimum possible with any division system.

26

Yes, when 10 coins are exchanged for 1 coin, then 10 coins need to be burned and 1 new coin created. I should have made it more clear.

If the farming reward is 0.001 safecoins, then yes that means an additional load. But if the farming reward is larger then there is less extra load.

The best solution is if micro transactions can be done directly with safecoins. My solution is only for ordinary payments and farming. But I thought it would be useful for efficient wallet to wallet transactions.

27

I doubt the reward will even be 0.001 for the majority of the time. Just think about world wide serving up of data and 1000 GETs per SAFEcoin. And thin consider the 100 million people using SAFE per day. We have to consider at least that since the network is designed for much more.

There will be statistical times when PUTs are low for a period and GETs are high. 100 million people GETting a few thousand chunks in a day including MDs (3K to 1MB each chunk) and paying in 0.01 denominations will represent a very large amount of coin. 10^8 people * 10^3 chunks ave = 10^11 rewards of 1/10^2 (0.01) ==> 10^9 coins worth PER DAY in rewards.

The only way that can be sustained is to have a lot of PUTs occurring at the same time. Even 0.001 as the minimum GET amount is too much in a sustained manner.

At 0.001 reward minimum means that PUTs are > 0.001 and because minimum denomination is 0.001 then minimum PUT amount is 0.002 So you would then be saying that to upload a 4.7 GB DVD movie rip will cost a minimum of 9.4 safe coin.

When you start thinking about it 0.001 as a reward will be during times when space is scarce and the network wants more farmers. The current algo allows for GET reward to be as low as 1/10^18 when available space is plentiful. Only when available space is critical will the reward be anywhere near 0.01 per GET.[quote=“Anders, post:26, topic:398”]
The best solution is if micro transactions can be done directly with safecoins. My solution is only for ordinary payments and farming. But I thought it would be useful for efficient wallet to wallet transactions
[/quote]

Yes and that is what was proposed last easter and I plan to expand on that soon. Using a balance in a Safecoin like MD (wallet master MD) will solve the additional load problem, allow division to 1/10^18 of a coin as easily as 1/10 of a coin and be secure.

Denominations maybe an outwardly elegant solution, but when using actual storage objects to implement it, it becomes cumbersome and a heavy load on the network.

Its only because you suggested using denominations for Safecoin division that I pointed out these issues. For a general transaction coin/token apart from Safecoin then the there maybe no issues in using it. The problems come from the uses of Safecoin, its more than currency and heavily used by the network for its operation and the use of amounts as low as 1/2^63 (~ 1/10^18)

3 Likes