Continuing the discussion from Will Safecoin Costs allow Realtime Collaborative Editing?:
After thinking about this proposal for a while longer, I’m actually strongly in favour of this idea since it’ll keep the value of a single SafeCoin lower. The reasons:
- The average human is not good in thinking in fractional figures. For example, the fact that when making small payments in Bitcoin we are working with values like 0.000432 BTC is considered annoying by many.
- The less economically/mathematically inclined tend to intuitively value 100 coins worth $0.01 more than 1 coin worth $1. For many people spending over $100 for just one-third of a Bitcoin feels like a very bad deal. This may be hard to believe, but I’ve heard several people who I’ve always considered rather intelligent expressing this sentiment when discussing Bitcoin with them (including my dear mother).
- Higher amounts of coins feel cooler. This I’ve heard being cited as one of the reasons for the success of DogeCoin. It feels better to receive or give a tip of say 5000 coins. Far cooler than 50 coins.
- The devs have expressed the desire to post-pone implementation of SafeCoin division.
- The current value of a MaidSafeCoin is already above $0.05. And we’re not even post-launch yet. Nor are we in BETA. Nor are we in Test Net 3. We’re in Test Net 2.
If MaidSafe is serious about it’s ‘secure access for everyone’ ambition and wants to have many millions of users at some point, then a higher SafeCoin cap is highly desirable. Now is the time when it can be done without causing any value loss for anyone. Also, it’s not like this is unheard of. Ripple currently has 30 billion coins. DogeCoin 97 billion.
As @TylerAbeoJordan suggested, the MaidSafeCoin:SafeCoin exchange ratio could be adjusted to match the increased cap.
Technically, raising the cap should be very easy. From the white-paper:
[ 32 bits: Token ID | 224 bits: ID padding | x bits (x <=
248): Subdivision bits | 248 - x: Random | 8 bits: Value of x ]
The initial part (Token ID) inherently limits the total number of
tokens available to 2^32 since each token must have a unique ID.
The second part (ID padding) must be predictable (e.g. it could just be
all ‘0’s, or it could be the ID concatenated 7 times). Its purpose is
to force all subdivisions of a given coin token the same trusted group
of vaults to eliminate the need for network traffic when handling such
This means by simply making the Token ID longer than 32 bits the total cap will be increased. Every added bit multiplies it by 2. If for example we’d make it 36 bits long, that would multiply the cap by 16. The extra bits can simply be taken from the second part (ID padding), so the SafeCoin data structure would still be the same size.
So far I can see three (minor) drawbacks:
- The extra SafeCoin records will cost extra storage space on the network. As a percentage of the network’s total capacity it will assuredly be negligible though.
- A handful of people might scream hell and murder because they completely misinterpret the meaning of this change, missing the point that the amount of SafeCoins they receive for MaidSafeCoin or farming or whatever would be multiplied as well by the same amount as the cap.
- Initially the network would need to handle more SafeCoin transactions compared to with the current cap. After we cross the point where with the current cap division would be used a lot, this is no longer true, since transacting two divisions of one SafeCoin is as much work as transacting two whole SafeCoins.
In my view the drawbacks don’t even come close to the benefits that are gained. I really think we should do this in order to be prepared for mass adoption. MaidSafe underestimated it’s own popularity before with the IPO and it backfired. Let’s not make the same mistake again? Remember, we cannot do this after launch. It’s now or never.