RFC 0061 — Safe Network Token Distribution

Autonomi Network Token
,
62

I’m not suggesting it de anonymizes transactions or anything just to clarify but more that if you don’t plan on going to an off ramp into fiat or just to purchase storage or other network utilities then you’ll still be taxed by a government but I mean what y’a gonna do? Most stuff gets taxed and I understand the complexity of the issues.

I just sit on a small amount anyways so. I’m mostly here for peoples rights to private and secure ownership over their own data and the possibilities that come from the design of SN.

1 Like
63

I don’t see the issue still. You said, i think that the point you’re making isn’t about being taxed on gains when converting to SNT, but that the KYC would somehow cause you to lose privacy on things after the conversion.

Maybe I’ve misunderstood your concern. I’m certainly not clear!

1 Like
64

If you got your MSC anonymously in the first place. There were avenues early on. Otherwise I guess it doesn’t matter as most exchanges require KYC and y’a know, blockchain.

Not a showstopper to me or the rest it seems so, carry on!

Cheers

3 Likes
65

I know the “real world” isn’t usually elegant and ordered and pure and simple, like a beautiful little equation that captures the relationship between two physical forces… It’s messy, and strange, and complex, and disinterested in our aesthetic feelings the vast majority of the time.

The Safe Network is a “piece of engineering”, though, and as such, ideas about how the world is, or how the world can be, get fused into such a thing. My feelings upon discovery of the project’s existence were feelings of shock and awe that someone had managed to maintain such a clear and simple vision in spite of all the drivel and inanity around us in the messy late-capitalist hellscape we live in.

Reading this thread I feel hugely mixed feelings. I sympathise very much with the MaidSafe team attempting to deal with a world which has become far more horrid over the last fifteen years, and I do believe that they are trying their very best to find a way to stay true to the Fundamentals and get the Network onto its feet in an environment far more hostile than what even very pessimistic commentators had been imagining. In terms of human freedom and general cohesion, our species is nose-diving. Authoritarian laws are proliferating, and that is the world that the Safe Network will be thrown out into.

I sympathise strongly too with the people who feel that the project has capitulated, with the recent use of words like ‘censorship’ and other corporate-sounding statements that seem to be leaving the door open for some form of centralised governance.

Perhaps it would sum up various criticisms made recently to say that it almost feels like MaidSafe are trying to micromanage a process that they cannot and should not touch. That actually controlling such processes is possibly a (genuinely) impossible task.

I’ve no solution to offer here, and I don’t intend to criticise either side. I’m more partial to the cypherpunk/launch and walk away camp, but don’t know enough about these things to get emotionally involved. I find it unfortunate and upsetting, generally, that the discussion can’t be more constructive.

To the disgruntled project followers, I would remind everyone that we only ever had the promises of David and the team to go on, and what we’ve got now is the same. Contracts, promises, legal agreements, these are all words, and they’ve never been anything more than that.

It bears repeating though - the fundamentals are still there, Maidsafe have reiterated their commitment to them, and no actual action has been taken yet to suggest that the fundamentals of the project aren’t still the cornerstone of what’s being aimed for here. If an actual step is taken that goes against the fundamentals I’ll be alongside you roaring, but no such step has been taken.

So please, continue criticising, but don’t act as if the game is over and the company has lost its way. For fifteen odd years now Maidsafe have continued to fight for the initial vision, and there is no evidence that has changed.

To Maidsafe - please don’t let the picture of the world that we get on our 12" laptop screens affect too much your definition of what is possible. Yes, the situation looks dire, yes, protecting yourselves legally in all the ways possible and being assured that everything will be fine would be nice.

I am happy that you’re investigating all possibilities and facing these realities, but don’t allow the professional scepticism and conservatism and fear of the lawyer’s view of the world win the battle here. How societies react to things is what actually decides “the law”.

So yes, to summarise: the reality as to whether in five years time the developers are viewed as heroes or villains or have never been heard of because the Network was crushed so quickly and ruthlessly… I suspect this will depend primarily on how humans all around the world react to this thing when it’s unleashed. And, even though it may not always seem like that, I persist in believing that bubbling underneath the surface in human societies across the globe, the thirst for freedom and fairness and co-operation might be colossal, albeit hidden under mountains (and mountains) of crap.

Please stay strong and don’t let the weight of the world crush the vision.

12 Likes
66

I feel like your response, Jaybird, is in the wrong thread.

In any case, the one thing I don’t understand is how this is holding up the original promise of a 1:1 MAID → SNT conversion based on a 2^32 model. We were expecting 10% of the supply, so shouldn’t MAID holders be getting 1.05368 SNT per MAID/eMAID? I saw something about an overprinting of coins, so does that mean there is currently a supply of 452M on the market instead of 429M?

2 Likes
67

Question: Why was the following scenario mostly overlooked when creating the current RFC?

Based on all of the public discussions that have occurred here over the years, the above scenario or something close to it would seem to be an obvious choice (KISS). Perhaps @dirvine has some insight here and could shed some light on this?

3 Likes
68

Can’t say why @jlpell (wrote all this before I saw your tag edit). I’ve had very little to do with this RFC. I came back just the other week after a few months.
(I will try look at what you suggest though, next week)

I managed to raise concerns about one thing in the RFC (just the other day) which was thus excluded (unfortunately still mentioned in this thread though), and tweak some formulations to try make the options clearer to a reader.

The only other input from me was a few months ago, raising my concerns about such large share of supply being handled by a foundation. Committees and boards being funded by the network and holding most of the supply - that’s not a good recipe in my world.
Unless I’m mistaken (I can have missed it), that’s all that was ever discussed about that in the team (except for behind closed doors as management convened).

Reality vs Wishes

The problem in my view is this:

  • We don’t want large sums of tokens being controlled by sections.
  • We don’t want sections to be able to create tokens.

Why?

Because we don’t know of a secure way to do any of those now - nor do we know when or even if we will learn a way.

Thus, the decision to have total supply exist from start; all DBCs ever existing would come from the genesis DBC.

So, how are these remaining tokens distributed then, if not held by the sections?

The wish is to
a) Release them over time
b) Have decentralized custody of them

(Remember these two points. They are central to the reasoning from here on.)

To have sections hold them, or be able to create them, would solve both a) and b) immediately. If only we knew that we could code such a solution - in a timely manner and meeting all requirements (wrt security etc.).

To use some sort of non-PoW lock-box to accomplish a) and b) is a solution unfortunately equally unknown to us at the moment. The idea has been floated that we could device such a solution. We don’t know how, when or even if we can.

So what do we know here and now that we actually can do?

  1. Let all eMAID/MAID be the full SNT supply. (Thus no remaining tokens to be distributed.)
  2. Let the Foundation hold them.

That’s it basically.

Pros and cons

Pros of #1: Simplest possible, hands down. Everyone already has all tokens. The most secure solution. There is nothing to be hacked or misused.
Cons of #1: There are a few big whales holding most of it. There’s fear that they could hurt the price by dumping.

Pros of #2: It gives some sense of control of the situation. There is a board and comittee that can take good care of it.
Cons of #2: It gives some sense of control of the situation. There is a board and comittee that can take good care of it.

(If the meaning of #2 as a Con was lost on anyone, then there won’t be enough I can say to help there. It’s beyond my available time and skillset.)

So, what this RFC says here in my view:

We wish to code a solution to a) and b), and when we get to it we will really try to do so.
Should we fail, there’s option #2 (the Foundation).

An observant reader would say, Hey, you forgot to mention option #1.
It’s not forgotten. It’s just not mentioned. I cannot give any answer as to why. It’s someones decision.

Why like this?

From what I’ve picked up: The reason for this to need an outline here and now, is regulations. FINMA. There’s an application that needs to go in there pronto, and there needs to be some outline making somewhat sense to regulators.

Because saying we will try to code a solution, and if we can't.. well then we don't have a plan B, I suppose isn’t an acceptable answer.

That’s why the RFC looks like this, is my guess.

Enter the Community

Now, welcome community, and solve this for us all; what other ways are there?

There’s the not mentioned option #1. Can you stomach that over a foundation? Then push for it!

Something else? Then PUSH for it.

If you don’t, then this is what you’ll get.

And please do it in the most professional and civilised manner you can. Put in the time, the effort.
It is my perception that a few with lots of influence on the path of MaidSafe and SAFENetwork, are not so impressed by the community (nor any crypto community for that matter). Crassly extrapolated, just to give a sense of what I mean, they tend to see a squabbling, unrealistic, idealistic, crypto-anarcho herd (again, my extrapolation of observed conversations, take it for what it is). I often feel the need to remind that there’s real people with real skills in the community. The herd is there, but many others as well.
So, make your voice heard and make an unmistakable effort to solve the problems. If the intention is not clear enough, all impression that is left to someone already skeptic, is unfortunately that above mentioned. A small team like this needs a vocal community, otherwise there are a very few deciding an awful lot (while probably not feeling like that’s an issue at all).

My couple of cents. Make of it what you will.

31 Likes
69

Very helpful @oetyng and welcome back. The following quote is the key to a useful discussion IMO. This is what I hope we can do from here on, staying on the issues and not casting aspersions, implying stupidity etc.

I’d put it like this and add something about “PUSH for it”: if you don’t like the proposals or some aspect of them say what you want otherwise you get what’s on the table. But also don’t leave it there, show you understand both sides, explain the pros and cons that you see in the proposals and your alternative (and try not to be emotional when doing this).

4 Likes
70

I’ve had no input into this RFC beyond the much earlier discussions on this forum so I don’t know why these options were focused on and others excluded. Maybe for simplicity and speed, who knows. Whatever the reason it doesn’t prevent other ideas being discussed, and that is being encouraged.

I am content with what is proposed, though I understand why people are uncomfortable with the Foundation controlling substantial funds. It’s not ideal, so what’s the alternative?

Well technical solutions to move that to the network, but what if these aren’t feasible (eg secure enough)?

Then maybe issue all tokens to MaidSafeCoin holders (option #1). I’d reluctantly accept that, but I’m not convinced the Foundation is worse, we should debate those side by side perhaps.

Anything else? Well some say just don’t do X but most of the X’s were part of the original white paper so I don’t think that’s a starter without exceptional concensus.

71

Thank you for explaining Oetyng and I think this adds to my earlier question why we went from distributing all the tokens over current holders to having a foundation hold them and distribute over time. I personally think option 1 would make most sense even though I do share the concern that whales would hold too many tokens. It’s one of the very reasons I’ve been actively saying exchange access, new inflow through marketing & community building is essential even before the network goes live. You already need a good foundation before the network kicks in for it to be decentralised enough.

I do question why option 2 is chosen over option 1, as I personally feel that when all coins are in circulation and there is a foundation holding most of the coins, it will be pushing the price down either way. There is always a risk, is it being hacked, is it a foundation taking a different approach, is it a government stepping in. One way or another, current holders now will not reap the full potential of their early investment and most importantly it will be far less decentralised on network launch.

4 Likes
72

This is the point I was trying to make but I don’t have the time and skillset to get it into writing either. Is there no way there can be some sort of middle road where all the tokens are disturbed and then donations can be made to the foundation if needed?
If this is the simplest and most secure way surely it needs more consideration?

1 Like
73

I suspect most would prefer network automated solutions to the distributions which were out at the crowdsale (plan A). MaidSafe have said they will do their best to achieve this so the areas of contention are what to do if any or all of them can’t be implemented (plan B). Ideally objections to different options of plan B are never an issue, but we do need to consider them because we definitely need plan B in case.

I think we should try to identify the main alternatives and then debate between them. Currently the RFC purposes the Foundation control and distribute funds (option #2).

We’re reminded of the idea of distributing all new tokens to MaidSafeCoin holders prior to launch (option #1).

Would anyone like to propose other options for plan B?

If we can narrow these down to just two, then it’s easier to debate those side by side. We could just do that for #1 and #2, but first I think we should see if anyone wants to push for something else.

Personally I’m roughly equally unhappy with #1 and #2 so keen to debate them or hear about something better but so far I’ve seen nothing said that’s enough to sway me away from the RFC.

2 Likes
74

Maybe one’s preference between Option #1 and #2 could be made more clear if more details on the proposed makeup and operation of the Foundation were presented.

Who will be the members of the Foundation and how will they be chosen? How many members will there be?
What will be the qualifications of the members and who will be in charge of creating these qualifications?
Will some of the members come from realms outside of crypto or IT?
Will they all have the same voting power?
Would the Foundation’s makeup be much like a corporation (president, vice-president, secretary, treasurer, legal department) ?
How much more power than the other members will the president (or leader) have?
How often will they meet? Virtual or in-person?
What kind of individual liability will each member have for the actions taken by the Foundation and will there be some kind of professional liability insurance?
How will they be replaced if they leave?
How long will their terms be?
Will they be paid? If so, any idea of what the remuneration will be? Where will the funds for salaries come from?
What would happen in the extreme case of all or most members resigning (or being forced to disband by some governmental entity) all of a sudden for whatever reason?
What would be the annual costs, outside of salaries, of maintaining the Foundation? Where would the funds come from?
Would the Foundation have investigative or punitive powers (e.g. in case of suspect behavior of members)? If so, how will that work?
Could a token-holder appeal a decision by the Foundation, much like a stockholder can appeal a board’s decision in the corporate world?
Are there real-world examples of similar Foundations that have existed over a long period of time that we can study to ascertain their effectiveness or discover unanticipated challenges?

I’m sure there are questions that others might have also but I think, since the Foundation might play such a pivotal role in the success of Safe Network, we should have an inkling of how it might function, even though it will most likely be a work-in-progress, just like the network.

Addendum: Most importantly, what will their actual duties be?

Addendum 2: If Option #1 were chosen is there a way to mitigate the advantage of any whales?

8 Likes
75

The Tezos Foundation had a rocky and dramatic start due to a shady board member/con man but ultimately they got over it and they do great now, funding marketing, dev cons, hackathons, app developers, big name partnerships.

This can be very successful. Granted TF has a huge Bitcoin war chest but as long as things don’t go too sour in crypto the BGF could be just that for us, thanks BG!
I know it’s faux pas to trust any centralized entity/company/institution and I don’t trust many but it’s not helpful or healthy to distrust all imo. No judgment if you do personally but I do trust Maidsafe. The character and focus of the company has swayed a couple times but always realigns with the stated fundamentals and original vision as closely as possible at the given time.

That’s why I think this RFC is an acceptable and reasonable approach. So I too am happy with it but I do have some questions since that is what RFC processes are for.

@oetyng if all MSC are put into circulation at genesis and given to current MSC holders/addresses, how does that respect the initial investors 5% that was (I believe) pre ICO?

How does the network pay resource providers aka farmers?

Is the upload cost just passed on?

If the Foundation doesn’t receive any tokens then how do we pay out grants to core devs, app devs, etc?

Those things seem unanswered with that option. Thank you and welcome back!

9 Likes
76

… well, there’s so much I could reply to in this thread, but in the interest of keeping it simple (ha! not really), I’m just going to make a few points and leave it at that …

  1. (if you are thin-skinned, then skip this one) – This first point is a vent of my own feelings of frustration and it’s not entirely specific to the RFC … and I might be just a wee bit angry - I really hope I am wrong with how I am feeling here but this has been bothering me for a while now, so just gonna say it.
Summary

After all the years of discussion on this forum on topics related to the original paper that this RFC mostly mimics, I am wondering if there is really any point in having a discussion here at all, because it feels to me that we are just going to be ignored and that Maidsafe is just going to do whatever they want to do anyway.

For myself I’m but a bug, and more an agent of chaos than a good contributor here, but there are many really great contributors in this community. Maybe it’s wrong of me, but I feel pity for those that have put forth so much effort … and for what? I’m sure there is some example that can be given where that isn’t the case, but for the most part, it’s really starting to feel like this to me - hoping I’m wrong here.

So for this first point: I’d like to see this RFC updated with explanations going though PAST debate and discussion from this forum explaining the decisions here and why they are better than the alternatives that have been proposed over the years by the community – Yes I’m requesting that some real effort be put in by Maidsafe people here – don’t you even dare to ask the community to dig them up or to create alternative RFC’s - this should be the job of the PAID employees of Maidsafe demonstrating their respect for the hard efforts of the community over so so many years who put forth a lot of time and energy for FREE.

If you really care for our input (past present and future), then please show it with your actions, not empty platitudes.

  1. I’m mostly a pragmatist, and what I want most of all for SN these days is for it to get to beta - flaws and imperfections are okay so long as it’s stable and usable. So … what is the cost in time for this RFC versus:

Because it seems like this RFC (as it stands) is going to add a lot more time and effort before it can get to beta. It’s not even as simple as developing the code as the security concerns are real and there is going to have to be a fair amount of additional auditing and testing as well.

I feel I am not alone here when it comes to concerns that SN is going to end up being delayed by a lot of extra months if not more than a year from the added complexities involved in the network securely managing network-wide honeypots.

  1. Closely related to #2, I would like to know where in the road-map these network (layers?) are going to be fit into the schedule. e.g. baby-fleming, Fleming, Maxwell or post-beta? You may believe that such should only be a consideration if this RFC is approved, but I think the community would find that information to be of great import given the duration of the project so far … and hence for us to be able to assess which options might be the most pragmatic way forward.

I’ll leave it there … please don’t hate at me for #1, I really don’t like giving general criticism, but I believe it’s a real concern for the community and I’m not the only one thinking and feeling it.

13 Likes
77

@Bogard
Monero had a really shoddy initial distribution, doesnt seem to have done it any harm at all.

Edit.
It seems my memory and a very
quick search failed me spectacularly here

78

Thank you for this comment, @oetyng. Super helpful. Still digesting it and will hopefully be able to make the time to circle back with a less nonchalant response to the RFC.

1 Like
79

Also there should be funds for marketing and I think @Sotros25 and others would agree.

7 Likes
80

This is the model (perhaps 1:1 model is a better name or 10^0 model) that most cleanly represents the actual workings of an integer based digital cash system. (as opposed to say a rational number based system).

If we use bitcoin as an example, the real fundamental unit is the “satoshi”. ie, the integer number 1. What we think of as “1 BTC” is actually 100 million of these. So the decimai place was arbitrarily moved 8 digits. In fact, the decimal place is purely a display mechanism because internally all (properly written) bitcoin software when performing mathematical operations will represent 1 BTC as integer value 100,000,000.

This translation represent a small but non-zero (and unnecessary) hurdle towards clear understanding and clear thinking with regards to “what is 1 BTC?”, “how is it divisible?”, etc. And the arbitrary nature of the decimal point placement is distasteful to anyone that likes things to be clear, logical, and have a solid rationale behind them.

The rationale for the 1:1 model is simple. One token, ie 1 SafeCoin, is represented by the number 1, which is the smallest integer possible. The human representation and the machine/software representation are the same, so understanding and calculations are simpler. No translation is necessary! KISS!!! Machines and humans can both use Si prefix names such as kilo, mega, giga, to abbreviate large numbers and move the decimal point in a familiar, standardized way, which is also used in many other contexts such as distances, hard drive size, weights, chemistry, etc.

So for example we could use the term “100 megasat”, or “100 mega” which would be equivalent to 1 BTC. As price discovery starts happening, humans would naturally tend toward using whichever SI prefix is most useful to use as a whole number given the pricing of the currency around common commodities such as eggs, milk, movie ticket, etc. Thus we hopefully avoid the strange situation of a carton of eggs that costs 0.00032 BTC.

Further, all software that deals with BTC presently must perform a translation from internal integer representation to decimal representation for displaying an amount, and likewise translate from decimal to integer when accepting input amounts. While not especially difficult, it does introduce/require code that is not technically necessary, and an additional surface area for bugs. And this is for every single piece of software, eg: wallet, exchange, library, accounting, financial, loan processing, banks, and on and on. Why require this rigamarole?

In closing I view arbitrary decimal placement as a barrier to understanding for newcomers to the currency. It is an attempt to somehow “simplify things” for people which in reality complicates intuitive and full understanding and adds unnecessary cognitive load on ongoing basis. It introduces possibility of calculation errors and disagreements because humans will calculate based on decimal floating point values displayed on-screen which are then prone to rounding errors and will not match results performed by software performing proper integer calcs.

or so it seems to me.

If the RFC is going to continue with the 10^9 decimal placement rather than 10^0, I would like to see it contain a full rationale for that decision, based on something more valid and logical than “other cryptos did it”.

a final closing thought: if Satoshi Nakamoto had chosen the 1:1 model for bitcoin, people would today just be using it without a second thought and we wouldn’t even be having this discussion. It is only because he chose the “arbitrary decimal point model” that the cryptocurrency industry has grown up around it and regard it as somehow “natural”. People are naturally inclined to do what they are familiar with, even without any logical basis for doing so. I challenge the author(s) of this RFC to do better and provide a thorough rationale for their chosen model, or else adopt the 1:1 model and its KISS rationale.

speaking of authors: I do not see any author(s) listed in the RFC document. Please add one. (git history shows Jim Collinson as the commiter.)

edit: one additional point. With BTC, one typically hears that there are 21 million BTC that could ever exist. Yet this is a kind of sleight-of-hand because in reality 21,000,000 * 100,000,000 satoshis could exist. People think: there are only 21 million btc and there are 7 billion people, wow. That’s a very different thought than: There are 2,100,000,000,000,000 BTC units and 7,000,000,000 people. This is an example of how playing with the decimal point can confuse and radically alter people’s thinking. Again, because we are obfuscating the system rather than representing the system as it actually is.

In this sense then, the decimal point placement (of existing cryptocurrencies) can be thought of as a type of deception and/or marketing propaganda to make the token seem more scarce than it actually is. I abhor deception and marketing propaganda.

13 Likes
81

@bones, I would request that you elaborate further (mainly out of curiosity as to your definition of “shoddy initial distribution” in the Monero case). But I’d like to keep this thread super focused on the RFC. So let’s take this one to direct message or to a separate thread if that works for you.

To be clear, I think your comment is relevant re:looking for precedents, but a more thorough look at a certain number of these is something that I hope I can put together and circle back with as part of a better response to the RFC.

1 Like