I second that
Although I did like the idea of having dirvine’s instead of satoshi’s
4 Likes
Currently I’m with you except I don’t believe @danda’s ‘convenient units’ goal will be achieved, or can be achieved, with such changes.
Say we do as he suggests and it turns out that a ‘mega’ or some such unit becomes the unit of convenience, and say it is worth 1,000,000 units and that’s about a dollar (or pound, euro) which is the kind of unit value most of us work with in our daily lives. Just for illustration.
What happens then? Say a loaf costs 1.2 mega, what do you think people will want to use 1.2 mega, not 1,200,000 units. I think that’s the point actually but what’s the benefit? You’ve ended up with a unit that is convenient and that people will want to see in their UX, including decimal points, or suffixes of ‘million’ or ‘billion’ etc. Conversions are trivial in code, but still are being done. 
Maybe I’ve missed the point here - but it probably gets worse? Thinking forwards, just as one of the issues for people handling BTC has been the change in value over time, the ‘mega’ will also be subject to those fluctuations.
So we end up with some people using UIs that show values in mega, even though it’s necessary to pay using a tiny fraction of mega because the value has risen markedly. So my loaf might now be 0.00012 mega or 120 units. (Hope my arithmetic is right!)
At this point new software or updates could use a new unit of convenience, but this creates confusion. The number of units is displayed in some software, on some web pages, but not others. What do services show in their prices, different units of convenience, or have they stuck with just the smallest unit 
?
I suspect that once a unit is established you really have to stick with it. That’s why people have to deal with tiny fraction of a BTC. Once it was thousands for a pizza, later about a dollar and so on. Where will it be next year? Few ordinary people will ever think in Satoshis, and I’ve never seen anyone try to change the unit of convenience. How could that be done?
We don’t know the trajectory for our units or any chosen multiples but we should expect something like this to happen.
So while I’ve no great objection to using an integer unit and multiplying the number issued for each MSC as @danda suggests, I don’t think it solves the issue of ending up with inconvenient units. If not, then are the other benefits worth the confusion that changing this will cause after so long saying something else? I’m not sure.
Happy to be corrected if I’ve misunderstood the issue around ‘convenient units’. It’s important to thrash that out because it does seem to be the main attraction and I don’t think it will be achieved.
8 Likes
We had a discussion a year or two back about doing away with decimals (or limiting them) in favor of just expanding the supply by 10^X. I’m with @danda in that I highly favor eliminating decimals, or just going to a simple system the “every man” understands, like a two decimal system that many Western currencies operate under, and expanding the supply accordingly. This is supposed to be for the genpop, not the crypto people. I think spending 100,000 SNTs makes more sense intuitively to people than spending 0.00001 SNTs.
I realize the goal is to obfuscate that altogether with front ends, but if it’s going to be done regardless, why deal with decimals at all?
7 Likes
I’ve just argued above that this won’t work because I’ve that is established it requires value to change relatively slowly wrt inflation which I don’t think is likely to happen.
Will ordinary folks use 1,200,000 to buy a loaf? I agree that’s easier than a small fraction, so is that really the point rather than the ideal of a ‘convenient unit’? If we can reach concensus on what the options and likely benefits are then it will be easier to compare and choose.
2 Likes
Great points @happybeing. I’ve had the same thoughts.
You are correct that software would still need to do conversions in order to display 1.2 mega (or whatever unit).
It is also hard to say if or when the community as a whole would decide to shift units. With bitcoin we’ve seen several attempts at that, which have pretty much failed. Many wallets already give the option to display millibits and other options. But still most people stick with “whole” BTC or else just use Satoshi, especially when calculating mining fees. So those seem to be the two units that stick in people heads and that the markets prefer. But also, at this point in history most people are not buying groceries with BTC and pricing is generally done in fiat with a machine converting to BTC. So we have not yet moved to a situation where any crypto is the default unit-of-account for goods.
I’m pretty sure though that humans don’t like pricing things in .0036 amounts. A unit shift might come quickly if/when a crypto becomes stable and widely used. The experiment is still running.
For me this proposal is really about these related things:
- Keep things as simple and clear as possible.
- Truth in advertising. Tell people the total number of available tokens from the very beginning.
- Make it easier to learn and understand.
I can tell you that even as a software engineer, I initially fell for the line that there are “only 21 million BTC and 7 billion people”. It took years before I actually did the math to work out that there are 2,100,000,000,000,000 satoshi units, which is about 270,000 for each person on the planet using a population of 7.7 billion. And I realized that as BTC value increases, this is the true fundamental unit we are working with.
I feel there is a moral gray area around the way Satoshi N. placed the decimal. In principle, the information is out there. Anyone can calculate these values. In actuality, almost no one does, and we simply accept and base our investment decisions on the idea that “there are only 21 million”. Does it matter in the end? I don’t know. But I do have a strong suspicion that price discovery may be distorted by this obfuscation. Who knows, maybe it even causes extra volatility and has made it take longer for BTC to reach stability.
The lightning network makes each satoshi divisible. iirc, it adds another 4 decimal places. If lighting becomes widely used, this makes even more total units available. Most people think this is just fine, because it is “just adding decimal places”. Maybe they are right. Or maybe it is a new and tricky form of inflation that actually dilutes value.
I don’t pretend to have a full and complete knowledge of how these things can and will play out. I just find them interesting to think about.
I do have a strong preference for simplicity and transparency in systems though.
Also I just think it is kind of an interesting experiment and an area to innovate/differentiate, since I don’t think any cryptocurrency has done this.
If the community doesn’t like the idea, that’s fine. I just wanted to ensure it had a fair hearing though.
12 Likes
I think that having the smallest base unit as The Unit is a great idea, and simplest to understand, this kilo, mega, etc.
2 Likes
Right, instead of long decimal value we say 20 nano as if it was a denomination. If I’m understanding your reasoning.
1 Like
I think we need to understand what the likely useful multiples might be, which we can estimate based on current MSC per dollar, and then imagine how these multiples might change if the value rises by x1,000 x1,000,000 x1,000,000,000 etc (or something like that).
I say this so we don’t keep saying ‘mega’, because I think it might be something much less cool and less ready to understand. If we’re thinking about ordinary folks we should figure out what it might mean in practice and how they would feel using those multiples.
Anyone fancy working this out?
EDIT: @danda thanks for the reply and clarification.
8 Likes
I think this is a good reference. Table of Metric (SI) Prefixes.
I think the useful ones are: kilo, mega, giga, tera, peta, exa, zetta, yotta. Yotta is 10*24, is that enough? Deka and hecto signify such a small difference, that I find them not useful.
I don’t think it’s important if we land eventually on a “cool” one. In my opinion, the important thing is to use only multiples of the base unit and not subunits at all.
Maybe maybe not, but I think it would be useful to give people something concrete to comment on such as current value of ~$1 would be ‘exa’ (not worked out just for example), x1,000 ‘zeta’ etc. There’s no reason why we can’t work that out now so I think we should do it. If nobody does it first I’ll do it when I get time but I don’t have it right now.
If you check my post here, I had a bash at some rough numbers a while back
4 Likes
I really sympathize with this reality.
Another one is security. In fact, it’s the security aspect (and less pressure on individuals/foundation members) that really has me pushing for decentralization. It’s the whole point of decentralization. These two points sound contradictory, but what I mean is that given the choice between a large number of people holding most of the supply vs a foundation doing the same, I rather the former. I know the former includes the whales issue, but if the main concern there is them dumping that’s actually a good thing.
How is gaming of this system going to be prevented? How will most of the supply not end up in the hands of a few? Essentially people are being rewarded for uploading? Beyond the numerous economic arguments against it, it’s rife for abuse, and it puts a lot of responsibility on the shoulders of the foundation to ensure it works well. Too much complexity.
I feel it’s actually the opposite. I feel like the people disagreeing with the RFC are actually trying to stay as close to the original promise as possible while the current RFC changes things dramatically. Here’s why:
Thank you for breaking this down. But doesn’t this violate the original promise?
In the Original promise, genesis only includes:
- 5% maidsafe investors
- 10% ICO coins
- 85% pool owned by the network to be farmed (and distributed between farmer and dev rewards)
So only the first two groups represent the totality of the supply at the genesis singularity. Meaning, the network royalties pool does not exist at genesis but only starts kicking in as new coins are farmed.
The current RFC breaks that fundamental promise. And this before we talk about breaking the original max cap, concerns with automated distribution or not, centralized control of the new 15% carved out at genesis, should entire supply be distributed to maidsafe investors and MAID ICO holders, etc. There are many concerns with the present RFC that’s being reduced to one issue by many here.
Maidsafe also has certain obligations like the 20M token loan, etc. that I actually personally feel should come out of genesis. But being very clear about that is important. Right now, the genesis distribution itself breaks the initial promise in my view. We should address that first before we even get to the other issues.
4 Likes
Put differently, and staying focused on the distribution question, it would’ve been a lot more consistent with the original promise to me if the RFC had said:
As with the Original promise, genesis will include:
- 5% maidsafe investors
- 10% ICO coins
- 85% pool owned by the network to be farmed (and distributed between farmer and dev rewards). And we’re trying to figure out how to go about automating this. If we can’t (which I’m actually a realist on this) we will consider the alternative option
Alternative option, genesis will be:
- 5% maidsafe investors
- 10% ICO coins
- 17.65% to network rewards royalties to be controlled by the foundation (i.e., 15% of 85% total remaining pool that was to be owned by the network
- 67.35% to be distributed to Maidsafe investors and ICO coin holders (i.e., 85% of 85%. Note no double dipping with network royalties rewards).
3 Likes
This is how I read the RFC and I do agree that its a necessary step in order to get a release candidate version in the foreseeable future.
If it got to the point where you have to “air drop” the remaining 70% then perhaps change the reward mechanism for farmers to distribute the 70% over say 3-9 years. IE increase amount of SNT to be distributed from a upload payment by some percentage. Thus if 1 SNT is spent to store a file then 1.05 SNT is distributed as per the RFC. 5% maybe too high but some %age could be figured out to spread the distribution over 2+ years allowing time for new farmers to be rewarded with early adopters bonus. Maybe taper off the bonus over time to ease the impact of it being used up.
yes i know some will call it this or that, but in my opinion it is way better than an airdrop of the remaining 70% and the tax implications it would immediately bring. Over time the tax implications will be much lower even to the point that for many it could even be under a taxable level. The airdrop is much worse than a bonus over time, so if airdrop has to be then do the bonus which only requires adding a %age to each amount received for distribution.
Oh you already thought of the bonus idea.
Its not a subsidy on upload, the cost to upload stays the same, the bonus is using the upload amount and some of the 70% SNT remaining as a bonus
And to stop any issues when its used up then just have it taper off as time goes on. Like 35% of the remaining in the first year (or uploaded amount), 25% the next, 15% the next, 10% the next, 5% the next and 4% the next and 3% the next, 2% and finally the last % the next year. 9 years and the effect of it ending will not even be noticed. Doesn’t have to be years, could be when a certain amount (estimated) is uploaded each stage.
In my experience of many years and opinion, it would be better to go for u128 and have 28 decimals and use updates to allow more decimals to be allowed. IE at first allow 9 places and enforce the lower 19 places to be zeros, except for network payouts allowing more accurate division of reward payments. Then during a set of updates later to the node software the number of decimals can be increased to say 12 places and enforce the remaining 16 decimals to be zeros, except rewards payments.
Especially since paying a bonus on rewards tapering off over time is a much better solution that benefits early node operators (early adopters) incentives and the bonus tapering off so that when it ends no one will even notice.
I suggest going u128 to hold values allowing 28 decimals which is massive since the divisions allows atom sized divisions. IE no one could effectively use it in our reality but does allow any amount of decimals to be used and increased by simply reducing the enforced lower decimals to be zero
See above I simply suggest using u128 (28 decimals) and limiting used decimals by enforcing lower decimals to be zero and reducing the enforced zeros when more decimal places are needed. This was the apps, the code code etc does not need material change, just the magic number of enforced zero lower decimal places.
In this reality we live in, 28 decimal places can not be practically used, but chosen because that is what a u128 gives us.
With the way the numbers are stored it is an integer 19 digits in the RFC (u64) and I suggest making it 38 digits (u128) and the lower digits enforced to be zero. The number enforced to zero determines the number of decimals SNT have.
u64: 1.0… SNT == 1,000,000,000 stored in the u64
u128: 1.0… SNT == 10,000,000,000,000,000,000,000,000,000 stored
This is simply FIXED POINT representation and used in computers for over 60 years to reduced the computation when floating point is inaccurate for many decimals and slow. Fixed point is integer maths and always precise.
The wallet programs will display 1,000,000,000 as 1 SNT for u64 and 1,000,000 as 0.001 SNT for u64
Maybe also explain that this is Fixed Point storage. It has been used for over 60 years to represent numbers with a certain number of places and store as an integer. People might understand this easier.
Don’t use the full 19 digits, just use (approx) 2^32 x 10^9 and keep it as 1,000,000,000 units to 1 MAID so that there is absolutely no confusion. Using the full 19 digits will cause confusion no matter how well you explain it.
To me as a human it is extremely important to follow the original documents and be easy to not get confused. It’ll save you so many issues in the future when people get confused.
6 Likes
It clearly acts as a subsidy.
Not that it will make any difference, but my vote would be for this subsidy to be paid out at a flat rate over 100+ years.
But opinions are like …
I don’t think the team really wants feedback, they are simply posting these RFC’s so they can say that they did. If they really wanted to know the community position, they’d do polls of their best options. But they are afraid of polls as if they decide against the poll, then they’ll look bad.
I hope I’m wrong on that, but that’s what it looks like to me … so all of this community chatter is just that.
The RingCT implementation is limited to u64 by the bulletproofs library. I suppose it could be made to work with u128, but its already slower and larger than we’d like and that would make it much worse.
7 Likes
You are missing elements of the original promise though, namely:
10. Day 1 Injection
To reward investors and developers involved during the early stages of this project, it is proposed that 30% of all safecoins will be injected into the network on day 1. Up to 10% will be available for purchase via the crowd sale, 5% for the existing MaidSafe investors, 5% for the SAFE core development team and 10% for the general developer pool.
and
Secondly, developers that create apps that do not charge end users and are of benefit to the community will also be rewarded. The issuance mechanism for both groups will come via the [MaidSafe] Foundation.
and
The MaidSafe Foundation will initially:
- Hold and distribute safecoin for developer pools
- Manage issuance of MaidSafeCoin to funders and existing investors
- Hold all patents and use safecoin to pay for the upkeep and further patents for all projects (until this sphere cannot be litigated against, the MaidSafe Foundation will act as the holder of defensive patents, of which there is already a considerable worldwide portfolio, to protect the decentralised Internet).
- House the MaidSafe team in an HQ and provide funding for independent development pods, worldwide
- Provide finances for the core team and development pods for a period of at least three years
Some of this is obviously outmoded and thus deliberately excluded from the RFC, for example the Foundation providing an HQ for MaidSafe, but other elements are pretty significant elements to the proposal, and ones that people have even built businesses around.
It’s easy to characterise that initial 15% injection to the Foundation as some scheming money grab by a organisation seeking clandestine control, but remember this is to fund and reward and uplift developers building and fostering the Safe ecosystem. Some of them have been doing that for many years based on these promises and have yet to realise any returns. Many are loyal members of this community on the same long road as the rest of us.
It’s there to kickstart the Network and the ecosystem that surrounds it, fostering businesses, communities, and movements. It’s been part of the prospectus the whole time. I think it would be somewhat of a betrayal to pull it now, don’t you?
What has changed?
The main thing that has changed in the RFC is the more general pooling of Network Royalties, vs this hard split of 5% / 10% core to App dev. Because this lacks the flexibility to meet the needs of the Network and developer communities as time goes on.
We can predict that the App Developer community and resource requirements will become significantly larger that Core Development needs over time, so it would seem strange to keep this hard split, and amass a large core surplus.
Additionally we carve out scope for other PtX type schemes in future, rewarding other endeavours and contributions — schemes that the community has been very vocal about over the years.
We also make sure the Foundation can actually fund the administration of these things practically by being explicit about how it can pay out, and providing for the financial means do it, i.e. basic staffing, legal, banking, auditing, and hosting costs. None of this is currently provided for in the original white paper, and it’s all necessary in order for the Foundation to actually function in the role it is tasked with.
On top of that, as already stated, there needs to be a legal entity ready to issue these new tokens, which can then go on to provide what MaidSafe cannot—access to markets for SNT—enabling economic on and off ramps for the Network through, for example: exchange listings, funding development of P2P trading, traditional merchant services integration, OTC sales to institutions etc etc.
These things are important for access to the Network economy of course, but more than that, they also allow the developer community to be properly supported too, particularly in the early days after launch.
These things can’t be overlooked.
9 Likes
Was coming on to note this. thanks @danda 
Aye. There’s a limitation here in how much divisibility we can offer while maintaining transaction privacy.
Atm it’s unclear what the impact of such a change might be performance wise. As we get DBCs integrated and the data payment flows in place once again, we’ll be able to see a bit more clearly the impact of u128 and test things out 
9 Likes
Again, I think this is pretty unfair.
Polls on this forum have their place, and perhaps they could be utilised to gauge sentiment for elements of this, but remember:
- They will only sample a tiny fraction of investors, ICO participants, MaidSafeCoin holders and other interested parties
- There are contractual obligations bound up in these proposals
- There are likely statutory obligations and due process requirements
- There are large sums involved
- Forum polls are gameable
I’m sure you realise all this. So to some degree it feels a touch provocative. Like setting things up to say, “oh look, they didn’t do a poll, they just don’t care about what you think!”. When in reality this RFC aims to stay true to the vision, the original prospectus, and give flexibility to accommodate features and desires from the community that have been pressed for years. E.g. PtP, exchange listing, marketing, fostering a broad ecosystem etc.
Please feel free to give specifics as to where you feel it misses the mark, but I would urge you to do it in good faith, as we do the same.
14 Likes
A subsidy acts to subsidise the upload costs. This is clearly is not doing that. The upload cost would remain exactly the same with or without the bonus.
It definitely acts as a incentive for farmers to farm, and to join early on when we need more for the security of the baby network.
The upload cost has to remain the same or it is not bonus for farming. If the cost of uploads reduced then it would be a subsidy and incentives uploading.
For instance in retail business, if I pay a bonus to staff it is definitely not a subsidy for customers. And that is the same for farmers getting a bonus
Oh that is a bummer and if it remains that way before release candidate then u128 would likely be too much for what its worth.
Still implement with u64 and when u128 is possible an upgrade path could be made with like a SNTv2 and the network could accept both (dual code on the DBC data process) and the logic around the DBC data would remain the same, just the process of the DBC data. Thus people would spend their u64 DBC and receive one or more u128 DBCs. Just a quick thought, maybe do it in 5 years or more after we see if 9 decimals is enough.
4 Likes