Safecoin divisibility

Development
244

I’m up to speed with your reasoning. This same line of reasoning is why 64bit cpu’s are currently built with 48bit hardware addressing to mimic a 64bit virtual memory space. Intel and AMD have decided that only after disk space is cheap enough will they spend the effort to have 64bit hardware addressing. However, SafeCoin is software. I was thinking more in terms of an adaptive mesh refinement perspective. Just because you use 64bit addresses, doesn’t mean that you need to create all 2^64 objects initially. The total number of objects that can possibly ever exist is fixed, as well as the relative abundance of denominations will be fixed according to a scheme like that @norimi outlined, but the actual storage allocated to them would grow as they are farmed and the network expands. I see this different than inflation since the total amount of currency that could possibly exist will always be fixed, although huge. As the network expands its capacity to perform more transactions per second also expands. It is conceivable that this expansion also leads to an increase in SafeCoin fiat value thereby driving demand for using the lesser valued denominations.

As far as fairy tales are concerned, right now I can go online and buy a hundred TB of storage for reasonable cost… how much will one be able to buy cheaply in 50 years? I don’t think a few 100 PB on a single “desktop” would be unreasonable. A population of 15+ Billion people spread out on multiple planets… that will consume a lot of data. But then again, isn’t 640K of ram more than anyone would ever need?

1 Like
245

After thinking more about you 1-2-5 series example in regard to 64 bit addressing, would this not allow for fractional denominations to fit in nicely to yield a total of 79 denominations?

1/2
1/5
1/10
1/20
1/50
1/100
1/200
etc…
1/2,000,000,000,000
1/5,000,000,000,000
1/10,000,000,000,000

246

What do you consider the maximum size of the safe network if it existed now and 1 million nodes?

!0 PB 100PB?

Lets say average vault is 100 GB means 100PB So you simply could not have 48 bits for coins with a large network in todays (couple of years time) And the network is unlikely to be a million nodes at launch in 2 years?, but more likely in 5 to 10 years. So the time is even longer.

And if disk storage increases 10 times every 5 years then 184 million PB will require 30 years to even have that storage. But were are you going to store the data people upload if you require the whole network to store your coins.

No 48 bits even is unfeasible for a decade to even store the coins and to keep data for people you need the network to be even larger.

Lets be clear - The network’s purpose is not for coin storage, it is for storing valuable data

SAFE is not a crypto currency but a storage network that provides services

The balance idea gives you every advantage for sub-safecoin without the absolutely massive storage overheads that cannot even be accommodated for 3 to 4 decades. So why adopt something that is intriguing and sounds good (lolly ideas) instead of something that is simple and straight forward but isn’t a lolly idea.

1 Like
247

Why not have something like bitcoin halving.
Well the idea is in certain total sizes(at 1 Petabyte, 100 petabyte, 10000Petabyte total sizes as example) of the network every coin gets duplicated. So maximum coin size gets doubled and every coin owner gets 2 coins. (the reason I call it halving is because possibility of mining a coin stays same while value of a safecoin halves. Effectivly halving mining rewards. How big of a problem this would be I wonder ?)
It should be realitively simple to implement. Basically if you have coin with adress 111 you get two coins with 1110 and 1111
So the main idea is if safecoins stay relatively in low value the need for divisiblity would decrease.
Just an idea I had, probably bad but I still would like some opinions on it

248

I am considering a 64bit address as the “name” for the safecoin denomination. I am not saying that the network should deal with 2^64 objects on day one, or any time soon. The use of 48 or 64 bit address allows one to account for denominations both very large and very small 1/10,000,000,000,000 denominations. If you wanted you could stay with 32 bit addresses, but I think you would want to rescale the 40 denominations @norimi described with face values ranging from 1/1000000 to 2000000. It would get tricky if you ever wanted to at least move up to at least 48bit at a later time though, which would require a 64bit integer to hold the address anyhow.

Based on a superficial understanding of this system, I don’t see how it doesn’t satisfy the requirements.

  1. Everyone has the same chance of getting a large or small denomination. Fair.

  2. Using this method still allows to exchange MAIDSafe to SafeCoin at 1:1. If Someone has 10,465 MaidSafe, then they might get a 10,000SC, 4 of the 100SC, 3 of the 20SC, and 1 of the 5SC. If someone has a fetish for 1SC denominations then at that point they can trade their higher denominations in order to collect them. If the ICO stipulated that their would never be more than 2^32 SC, then just shift the denomination range so that there are more 1/1000 or 1/200000 SC notes rather than 1000 or 2000 SC notes.

  3. The entire address space of SafeCoins doesn’t need to be on disk day one does it? Let it grow with the data. This might look like inflation but the total number of denominations that ever will exist is known at startup. Think sparse matrix. Isn’t that what a DHT is supposed to do?

  4. KISS is subjective.

249

I didn’t notice. That’s one implementation of the same idea. My method doesn’t need the divisor be 2, the denominations be powers of 2, and the largest denomination have a single coin. It can be adjusted to meet specific requirements.

250

It maybe fair in people have same chance (but not so - see my post above)

But its not fair to the farmers who in general receive less than they would have with a flat system like the ICO described and what people based their investment on.

The reason it is not fair is that a few get great rewards when a coin is rewarded. So those (most people) who get one or two coins per day or week from farming will take a year to three to get one significantly larger size coin based on averages. And then on average that larger coin in no way comes close to making their earnings equal the earnings they would have got on the flat model.

Also to make this worse is that those who get a massive coin can then use that wealth to set up farming farms and thus increase their chance to getting another larger coin. So then the ordinary farmer has even less chance of farming a big coin because those who already have make it lopsided.

Then the goal of SAFE is to level the playing field rather than make winners and losers in some sort of large denomination lottery. Also the little people can only farm say one coin a week/month but with the level playing field it is worth a lot to them. But this denomination will mean that these people on average will get even less and one or two may strike it rich. And this is because those farming in richer parts of the world will get on average the larger denominations since they get more coins per day/week.

That is how it is extremely unfair.

Sorry you cannot - you changed the definition of the ICO defined safecoin. The ICO defined something and you cannot just go and change it. Otherwise people have legal recourse against Maidsafe.

Correct, but you must allow for a significant amount on day 1. Why? because micro transactions start on day one with tipping that I guarantee will exist as soon as it can. So there are billions and billions of micro and nano-safecoins exchanged on day one and likely to crash the network on day 1 since there just is not enough vault space.

It is relative not so much subjective. And there are obvious limitation to what is KISS

251

@neo all good points in your previous post. Do you have a link to where the ICO defined safecoin was described? Is it in the whitepapers on github?
I remember reading about how a certain percentage of MAIDsafe would be converted to SafeCoin on day one. Perhaps that just fixes the range of denominations so that there are more enough 1SC notes to hand out to the initial investors. I get your point about fairness. Perhaps that means that under the @nori farming starts at the smallest denomination first in order to allow for the micro transactions immediately. Larger denominations would get unlocked/farmed later.

2 Likes
252

40 bits sounds good, 32 is probably fine. 64 bits is impossible as explained.

It’s more natural to use 1, 0.5, 0.2, 0.1, 0.05, 0.02, 0.01, 0.005, … because the divisors stay the same through the entire series: 2, 2.5, 2, 2, 2.5, 2, …

The smallest coin can be 1 (full coin) or 0.01 (“cent”) or 0.00000001 (“satoshi”) or anything else. It is an agreement.

a) Choose the smallest denomination small enough that the market cap becomes about 2³².

b) Exchange 1 maidsafecoin to 1/2³² of calculated market cap of new version safecoin. It’s worth is as the ICO specified.

It uses different mechanisms than the original safecoin but it tries to stay safecoin.

I like the idea as a separate coin on the safe network. Mixing it with safecoin is messy.

My method gives granularity and expands the range of values with at almost no cost of complexity.

1 Like
253

Sorry I cannot, but a number of those investors voiced their disgust at ideas like even increasing the address space to 40 bits and giving everyone 256 coins for every MAID they have. So even though its just having 256 times the coins but everyone gets the equivalent value they were vocal. Some were OK other were dead against such a thing.

So look through the forums for the topics and hopefully you will gain the info. I was not around during the ICO so I never availed myself of that info directly.

254

They would get equal value. Disgust is not a legal term.

If the smallest coin is chosen as 0.00000001, market cap is 6,467,133,251. It is in the range of classic safecoin.

440×533 21.7 KB

Farming works with undivided coins. A pseudorandom address is selected deterministically. If it is not taken, it is given as reward. Divisibility can’t help with that, the address space would need to be extended for finer grained rewards.

Farming is already unfair. Equal doesn’t mean just. Most rewards go to the few with big farms as you said. With my method, small farmers with little power get a small chance to get rewarded for the attempt.

The difference between small and big can be adjusted: a) Fewer denominations. b) More coins assigned to the biggest one. Both gives smaller inequality. With the right numbers, it can be “just” not only useful.

@jlpell’s idea is a good solution. If the coins are restricted to a small subset of the denominations, for example the 3 closest to the current PUT price, the inequalities would average out very quickly. After simulating 100,000 farmers for 52 weeks with one reward a week, the worst average reward was 0.6923, the best 1.375, the median 1.0288, and the mean 1.0343 when only the 0.5, 1, and 2 value coins were available to farm. It looks fair.

It is easy to implement. At farming, there is a counter like a nonce. If the first address is not in available range the next one is selected, and so on. Everything else works as with classic safecoin.

All of this is concern for the young network only. Even without @jlpell’s idea. Most big coins would never enter the free pool after they are first farmed. They would not be used to pay for network services, but for commerce or store of value. The small coins would be used for paying for network services, available to farm again and again. At any given time, the coins with the value closest to the current cost of a PUT would be the most abundantly available for farming.

It means big coins would be mined at a time when farming is easy because most farming attempts would succeed. It both helps and rewards early adoption, apart from extending the market cap of safecoin with its 32-bit address space and without need for divisibility to a range that is more appropriate for global adoption.

3 Likes
255

Uhm - I didn’t see an argument speaking against @neo s proposal Oo…
Are there no arguments against it? If yes why do you keep discussing?

I was surprised by the simplicity of the denominational idea but since really small coin would be needed a lot I like the flexibility of neos idea a lot more to be honest… And since I see the cons only with the other concepts…

4 Likes
256

Why exactly would you try and justify the price for a solution that has a higher probability to cause a problem at some point…?
(maybe I’m just a little bit slow and don’t see the problems you see Oo then please enlighten me =)

2 Likes
257

I think you’re talking to me. Oo what?

Mine started as an independent proposal as a separate thread. It was moved into this thread by the mods. It is not about divisibility but the lack thereof, so I don’t know why. I hope this answers your question.

But I like @neo’s idea. I don’t like it much as part of safecoin, but I don’t reject it. But it deviates from the simplicity of farming. Farming may erode if much of the coins become frozen as change. Not sure that would happen though. It may be useful down the road.

(The following is without @jlpell’s idea.) My method would return PUT cost size coins to the free pool naturally when people pay with them. Large coins are not used for paying for services, so not returned to the free pool. They are useful for commerce or store of value. They would be farmed once, never to return to the free pool but that isn’t a problem. There are few of them so it doesn’t decrease the size of the free pool much and farming can function as designed.

After the large coins are farmed, everything works exactly as with classic safecoin, but commerce is much easier because any sized transaction could be done with a few coins of the appropriate denomination.

Thank you. Most coins would be small. Almost a quarter of the coins is the smallest, over half is the first 3 smallest. So, most coins are not very different sized than classic safecoin.

It’s unlikely to cause problems because it changes either very little or nothing about how farming works, depending on whether @jlpell’s idea is included or not. His idea restricts farming to a few denominations which answers the unfairness argument.

1 Like
258

aaaaaah :smiley:
sorry i somehow thought your and @jlpell s concept was the same :smiley: okay - then i will read up a little bit more before talking again =) doesn’t make too much sense to participate without being up to date and having identified the different options!

259

In the proposal farming remains the same. The idea of paying for each GET was only a suggestion for further investigations.

The proposal only freezes the minimum number of coins to supply change currently used. As people use up their change the frozen coins are unfrozen. It has the least impact on frozen/farming of any of the proposals. This is because you do not tie up 2 coins if you have 0.000002 in change. There is only one coin frozen for 1000000 x 0.000001 rather than 1000000 coins tied up.

But yes if it got to the point where only change is distributed around the network and no one used (or hoarded) safecoin then an update to the safecoin would be needed.

By then I would hope that the concept of multiplying the coins by 8 or 64 or even 256 would be acceptable. This way a lot of change becomes coins again and we get another couple of decades of proper farming of coins.

But still to have 4 billion coins in change only will take at least a decade or so because farming will take that long. And plenty of time for better systems to be implemented.

And the primary reason its a totally unfair system. A few rich and everyone else gets less for farming than they would have. I have explained above and pretty easy to see. If you mix mean and average then you may not see why

260

Couldn’t you just make the large coin denominations require more proof of resources before they are distributed to the vault providers? That way the same proof of resource is required for 1000 x 1SC as is required for 1 x 1000SC denominations. This would limit the early adopter incentive though…

261

You could. We could do a lot of things that would be cool.

Don’t misunderstand me the ideas have a lot of merit, but there are some downsides to these ideas from you and norimi.

If the denominations were basically in a ledger system and didn’t require data objects behind them then they might work.

EDIT: Ignore this paragraph. I was just rambling it seems since it does not fit in with this discussion
But there is a reason banks went to book entries rather than try to work with denominations (except for deposits/withdrawals) and that is the volume of coins/notes to be sent physically or electronically. (thinking micro & nano-safecoins not to mention pico-safecoins

Basically the issues with the two methods is that they require quite a number of workarounds in order to make them suitable for the concepts that SAFE are using

To incorporate the workaround you suggested requires changes to the simple farming rate system so that it has to check the denomination of the coin selected before allowing a farming reward. But you need the farming reward to be tried in order to know the address of the coin to try. Catch 22.

Thus any workaround requires significant changes, and then testing to make sure people cannot game it for advantage over others.

1 Like
262

Yes, because it was easier to establish fractional reserves and swindle people.

The concept of having a SC as an object/file seems more fundamental. No ledgers, no funny business. Using the real world analogy, coins can have different denominations/weights, just like files can have different sizes or addresses with different levels of uniqueness as described above with the trie/tree 1110101 left-right system. In the real world, one usually picks the proper medium for exchange. Normally you don’t pay for a car with pennies. You could but it would be a lot of work, (which I guess is analogous to my naive suggestion to just increase the granularity to be capable of 48-64 bit addressing). Rather, in everyday transactions you pick the right combination of denominations that makes your transaction convenient. Check’s and credit cards / ledgers don’t count in this analogy because they only exist due to the use of a 3rd party central/trusted authority and are not p2p.

263

Mmh or if you happen not have the exact right combination of cash with you you need a cashier /bar tender to give you change back

How often do you have the perfect combination or cash with you for paying the amount you want? :roll_eyes:

(yes I know not a fair comparison but you see what I mean I guess)

1 Like