RFC 0061 — Safe Network Token Distribution

Man, you have to quit trying to hang them out to dry for this.

There’s a reason the people developing SN and working at Maidsafe do so and not us. There are maybe a dozen really qualified vocal people in this community who’s input would truly matter and half of them get hired by Maidsafe. The rest of us are smart enough to reason and make sense of design decisions most of the time but we’re not the ones coming up with them either.

You feel as if they are a amusing us by asking for feedback because they never seem to take it, well sometimes the feedback might not be good enough to take but they are just too nice to say that. I feel as though they are being transparent and giving us the choice to agree or disagree and make our points and if it’s good enough or makes enough sense and isn’t a danger to the longevity of the project or launch then can be considered.

Even the conversion of eMAID, which was a monumental feet was not something they would put man hours into but did anyways out of appreciation for those community members that put themselves up. There’s still low volume and price is obviously at the whims of the overall market so it might still pay off eventually but so far not much has changed and they have limited resources. I am glad there are more choices and access though. That’s just one example of something else highly contentious.

Am I saying that Maidsafe should ignore it’s community or not be transparent or lack consideration? Absolutely not but I don’t think they really have either. Just because they don’t put out polls to let the community make the decisions that they’re on the line to investors for doesn’t mean they ignore the community.

Putting out polls for sentiment could make sense but it would also embolden the thought that somehow we are the ones making all the decisions when we bare zero of Maidsafe’s responsibilities. It just isn’t a great idea unfortunately.

4 Likes

You are confusing democracy with leadership IMO.

Polling after a focused discussion is needed to get the pulse of the community. Many here will read but not post, so there is no real ‘feel’ for what the community thinks - only a feel for what the loudmouths think. Hence the team can get stuck with a false impression and not bother to take the time to explain decisions that they’ve made because they simply believe that the community understands the issues, when in fact they don’t. This is why polling is critical - for leadership, not for democracy.

1 Like

Sorry man but I disagree and think you are confused.

If you give people a vote on a clear choice it implies democracy (which is pretty great usually IMO) and when the opposite happens then there is either outrage or a sense of powerlessness or unimportance that isn’t justified because it was misleading to start.

Even the word leadership seems misleading. Sentiment makes more sense to me. That can be a gauge worth tapping into but again I think polls give a different impression unless explicitly stated as not.

Just a difference of opinion I’m sure but hey.

4 Likes

Just to clarify—and not to rag on the boss :laughing:—but the notion of 5% dedicated to core rewards is no more, it’s a single Network Royalties pool, which can gives the flexibility to allocate the appropriate amount as per the needs of the Network.

5% might be about right in the medium term, say, but years down the line when the code is stable, it would seem strange to be locked into that, when a fraction of that would likely be required for core maintenance and research.

Likewise, it’s not likely (unlike App Dev rewards) that core rewards would be distributed in real time. That’s more down to the practicalities of things, and the again the flexibility required for prospective work, vs post-hoc, and the needs of core devs who might require things such as fiat payments etc.

7 Likes

I think the following reflects David’s approach very well and that this can be seen in the current proposals in the OP. Some see them as betrayal, but IMO they are consistent with the following narrative which is equally visible in the twists and turns it has taken to get the project to this point. Bravo David and team :clap:

[The quote is I believe from AI expert Kenneth Stanley who has done groundbreaking work towards Artificial General Intelligence and Machine Learning.]

8 Likes

(emphasis mine)

Specifically on “We don’t want sections to be able to create tokens”: Is there a thread where this is discussed more in length so I can noodle on it a bit?

I am very interested in why section(s) can be trusted to handle data in a secure way, run a bunch of rules for handling it, but not this data and rules for handling that.

4 Likes

Once a section can create tokens then the focus of malicious people will be to get control of a section then create tokens at a rate that doesn’t destroy the token “economy” nor attracts attention. Then that section will be a source of funds for the malicious people. This opens the possibility of a targetted attack vector.

Whereas if tokens are not created by any means then that attack vector is removed. One less attack vector. And if a section is taken over then the tokens to be stolen amount to tokens spent to the section, a really small amount compared to if the section can create tokens. The other advantage of taking over a section is to mess with data. Both of these things are bad for the network, but not something that is anywhere as attractive and much less damaging to the network.

My observations obviously. And this is considering attack vectors since the section should always be secure to being taken over. Think maybe in terms that the 51% attack on BTC is possible by say China, but never is done because the advantage is in BTC not being sunk. Reduce the attack vectors and the incentives reduce.

2 Likes

Maybe a stupid question, but what does it mean that a section has DBC’s? I guess it means that it has the keys appointed to it, but the DBC data itself is replicated all over, just like any other data, right?

Payments for upload are done via a DBC, so the section receives the DBC and then splits it up to reward nodes and the foundation.

Is this what you are referring to?

No, I am just wondering how the money is protected in a case of temporary network split or on case of data corruption etc. I guess I’m not understanding very well the whole system… Keys can of course be owned by on owner at a time, but the part of what the keys fit in, how is that protected, replicated etc. I don’t know if this makes any sense, really…

1 Like

Thanks for that Neo, it is important to understand the initial motivation. Was this debated, picked apart and analysed by the community elsewhere?

As I mentioned earlier the alternative also opens up to several new “targeted attack” vectors, equally and possibly even more devastating. Forgive the paraphrasing but you did sum up one facet well:

Once 70% of the supply is distributed across the network “somewhere/everywhere”, the focus of malicious people will be to game the many possible additional targeted attack vectors “automated distribution” method(s) will provide to them in order to get control of as many tokens as possible. It may not even be necessary to take over a section to do so but rather game the distribution algos and even socially engineer the offline governance structures as we have seen before. I would add that there are many types of malicious actors and one that aims to game the automated distribution “at a rate that doesn’t destroy the token “economy” nor attracts attention” is one only motivated by profit. We have seen quite a few cases in this sector where the aim of the malicious actor is to outright disrupt, degrade and destroy regardless of profit. I´ll wager there will be plenty of those types lining up for the Safe Network.

Following the line of thinking:

If sections can´t be trusted with this data, then why can we trust them with any data?

Leading to more questions (some rhetorical): Are there different levels of importance of data? So this particular “token” data is too important for a section, more so than other data we aim to handle and is a special case. What other more important data are we going to have problems with handling in the future? Will we then need methods to increase the security guarantees to handle “really important” data? So for one off the cuff example If one section is not secure enough, then perhaps two, three or more need to coordinate for “really important” data.

From a higher level on where is all this going and leaving aside the sadly too numerous cases of fraud, speculative excess etc that always come with it as sure as human nature. In the real economy and more so in CeFi and come-lately DeFi, there is natural move to a proliferation financial products that help get things done and solve real world problems. We all use them everyday even without being aware of it most of the time. The majority to make society better. SNT is just the first baby step. After and on top of it should come new financial tools and derivatives to solve some of these real world problems in a more efficient way that the Safe Network should hopefully allow. One tiny example discussed here previously would be the ability for individuals/companies to set up gift card issuing DBCs.

Will all this potential future fall in the “important data” category and require foundations, committees and the “automated distribution” scripts they control doling out genesis issuance, to be really secure? The distinction into “just data” and “important data so we can´t” is fundamental.

Additionally, there is also issue of audibility of supply. This becomes much a more complex and difficult problem to solve—and may be impossible while maintaining privacy—should the entire supply not be minted at genesis.

7 Likes

Its not so much cannot be trusted, but rather not making sections targets was the greater motivation.

I agree that sections should be capable of being trusted.

Your post is definitely thought provoking. I agree that DBCs could be introduced that deal with things other than SNT, but would have to use their own implementation. Maybe do a omni-protocol style of thing where they have a payload associated with a SNT DBC of a very small amount (1x10^-9). This could be achieved by encrypting data with key derived from the DBC itself and the data holds the info for alternative use. Obviously different things would require different ways to hold the alt data.

@JimCollinson Wondering if the DBC can hold a small payload, a minimum of an XOR address and decrypt key. Can this please be included as this would open up a huge area of secure asset transfers, Other coins, or any number of other ideas.

4 Likes

Each threat has different incentive structures and different kinds of impact and these are complex to understand and evaluate. So while this have been discussed on the forum I doubt we’ll get a full understanding of all the issues and it’s pros and cons. It requires deeper clearer thinking than we get here, although there’s no reason not to look at it again, maybe in a dedicated topic so that can be referred to if it comes up again.

For example, it is not true that being able to mint DBCs only has a profit motive. That could be used to disrupt the network by destroying the economy, rather than only milking it gently. That’s not hard to see but been missed immediately in this discussion.

As for “if we can’t trust the network to do this, can we trust it to protect other data?” that’s a valid question, best explored by asking what are the threats for the other data, the incentives, rewards etc for attackers. You can’t answer it with yes or no, but you can look at where the network is weakest and then decide how to make it secure enough for each aspect.

However, securing data isn’t an afterthought, the whole design has been created, adapted and changed over time to get a balance between security, efficiency, cost etc. If a new feature is then proposed, like having Sections mint or control vast sums, you need to look specifically at that. It doesn’t to throw everything you’ve done so far into question.

So there’s no need to suddenly doubt the suitability of the network to store other data. That’s not changed. By all means re-evaluate it, that can do no harm, but it doesn’t really belong in this topic and hasn’t suddenly been thrown into doubt because a different kind of threat is seen as too risky.

3 Likes

Very recently in this thread was a quick review on the limits of u64, u128. These are equivalent of hard “supply” limits. To breach those hard limits you would need to upgrade the libs DBCs use to handle more “supply” u64->u128, or fudge it and change the fractional system as you went over very well in the “Proposal for Nice Numbers”/“Many Units” post above.

I am guessing is the concern behind audibility of data as you mention: We may not have enough trust in sections to manage the data rules regarding issuance, even upto a hard supply limit provided by u64 for example. We should have enough trust in sections to handle the audibility rules for other data types however. Is that fair to say?

Why would there be more trust in “automated distribution” upto the hard limit provided by the genesis mint total but, not “automated issuance” upto the hard limit provided by u64 under the chosen fractional system? Is it not exactly the same problem? The key in my mind is: Guarantees about the overall rate of distribution/issuance which in itself is also appears to be the same problem for both methods. Perhaps the automated distribution methods envisaged are to have their rates of distribution controlled externally and so not dependent on any security guarantee´s of Sections/the Safe Network?

Note that the example is not even scratching the surface of derivatives that could possibly be built on top of SNTs (not involving new DBCs), but in the end all would ideally require depending on the security guarantees of the data auditing and handling aspects of sections and so Safe Network as a whole. A least if they were to be done in a decentralised way.

See my wager, bottom of third paragraph in my previous post.

Happy to see new (and old) threads on this topic. Any references to the last time it was looked at would be appreciated so I can get up to speed on the thinking here.

2 Likes

Different contexts are being mixed here (technical, governance, etc.), but to the spirit of the message that the community should just defer to Maidsafe/Foundation on all matters, I would advise reading this piece by Maidsafe’s own Head of Policy and Governance: The speculative fiction novel I want to read this year – Hi, I'm Heather Burns.

Here’s a quote from the piece, but I advise everyone here to read the whole thing in its entirety because it’s very relevant to the prevent discussion. “

"To its credit, the open source project has a global, vibrant, and wonderful contributor community spanning nations, races, skills, abilities, and perspectives. To its demerit, the project has no transparent governance, decisions about the project are not made public, and project officials are not elected by, accountable to, or removable by the open source community.”

I’ll come back to the governance vs distribution dichotomy and why it’s so hard to disantangle the two.

By the way, I would think that for a discussion like this, the Head of Policy and Governance at Maidsafe would be participating and engaging directly with the community. I find it strange that that’s not the case.

5 Likes

@oeytng Thank you for your articulate and insightful response. I’d like to offer a more detailed analysis than my “back of a napkin”/“back of the envelope” list quickly hashed out before.

The biggest issue I’ve had with this RFC is the seemingly haphazard way that the initial allocations were reformulated, the way “royalties” were described (horrible term) compared to “developer rewards” or “developer pool”, and what appears to be a vast increase in the role and power wielded by a foundation. I thought to myself, “Have a few years worth of forum discussions made me think that SAFE is something it was never intended to be?” In light of the current RFC I picked through the original whitepaper again to see if I had missed something before. There were a lot of good ideas in that original whitepaper! But there were also stipulations, uncertainties, and some vague aspects that were good to refresh myself with. Here are a few things I’d like to highlight from the original whitepaper:

0) A new internet and a foundation to promote it.

" This project is simply the beginning of a new Internet, one that we all own and nobody controls, this is the “Internet sans frontieres!” The MaidSafe Foundation will be a key player in this proposal and exists to ensure fair distribution of wealth, while helping to foster education and innovation."

A new internet, hurrah - but the foundation role should be no surprise as a potential fly in the ointment if not given the proper role… It’s been part of the picture since day one. Thinking back, I suppose this was less of a concern the first time I read the whitepaper, thinking at the time that the charity/foundation’s role of was smaller, and seeing that it had rather noble intentions compared to other offerings in the crypto space. Recent discussions have somewhat indicated the opposite, increasing foundation roles/power in a way that weakens the network. So there was a disconnect here when considering RFC0061 that leaves a bad taste.

1) Total Safecoin (aka SNT) to be issued will not exceed 2^32

"This paper demonstrates the creation of a fixed number of coins over time 2^32 (~4 billion), which can be further subdivided to facilitate trading. "

“Safecoin issuance will be capped at 2^32 (4.3 billion)…”
“The data structure of such can be illustrated as … The fifth part indicates the level of subdivision of the original token, i.e. it contains the value of x. This format allows the tokens to be split into 2^248 parts if required.”

There it is, stated at least two times. The safe network will have a 2^32 hardcap, period, period. Some level of divisibility was intended up to a max of 2^248. There could be less tokens available due to burning or loss, but never more than 2^32. This is something that the current RFC has violated and should be corrected.

“The crowd sale will enable a direct purchase up to ten percent of MaidSafeCoin. These crowd sale participants will be buying MaidSafeCoin, an intermediary coin that will be swapped on a 1:1 ratio for safecoin once the full SAFE network is launched.”

Opps, technical error happened and a few more than 10% were sold. That’s not the fault of the participants. That also doesn’t mean you can change the hardcap willy nilly. The hardcap and the 1:1 exchange takes precedence, and the % is recalculated based on the amount sold relative to 2^32 total coins.

2) Initial allocation of SNT, “Day 1 Injection” ie. Genesis Tokens.

MaidSafe will allocate 30% of the tokens 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.

So here were the promised outlays. This equates to the following amounts:

  • MaidSafe Shareholdings/Investors = 214,748,365
  • Core Safe Network Development Team = 214,748,365
  • MaidSafeCoin = 429,496,730
  • Developer Pool = 429,496,730
  • Total Remaining implicitly available for Resources Rewards = 3006477106

2a) The conundrum

So now we deal with “the conundrum.” A technical error occurred during MaidSafe’s crowdsale and a total of supply of MaidSafeCoin is now 452,552,412. That is a difference of 23055682 tokens, which is only about 0.537% of the 2^32 hardcap. It really doesn’t make any sense to even consider changing the hardcap**, and the remaing ratios relative to the hardcap, or divisility etc., to adjust for the glitch in the manner that was proposed in this RFC0061! - full stop.

@JimCollinson, @dirvine - The simplest solution here is that instead of exactly 30% of the coins being allocated on day 1, there will actually be approximately 30.537% allocated. This does not change percentage of total token supply promised to core developers and non-core developers, nor does it change what was promised to MaidSafe investors. There was never a promise that ALL remaining tokens would be issued to farmers, just that there would be a hard cap of 2^32. KISS. Problem solved.

3) Developer rewards

15% of all safecoin earned will be allocated to the developer pool. This will ensure the developer community is highly motivated and rewarded for providing free-to-use applications”

“It is possible that 10% of these coins maybe recycled if a an idea of automated developer awards comes to fruition.”

5% of the developer pool coins will be given to the core developement team.”

Here is a detail I overlooked before. The core development team will not get 5% of total earnings/farming rewards issued. Instead it’s 5% of the 15% set for the developer pool = 0.75%. If we review the math, that means there is a missing 4.75% of earnings in the developer pool are free to be used for something else. Is this where Pt* comes in? Is this just an administration or “governance” fee taken by the foundation? That’s a quite large administration fee, yikes! There is too much left to the imagination here, the vague wording needs to be corrected.

4) The role of a foundation

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

No further actions can be taken by the Foundation, unless the authority is requested by the community to add additional objectives to this list

The original plan for the foundation specified interesting roles. Can the community ask that the foundation have certain objectives removed?

Presumably the MaidSafe Foundation roles will be dissolved or absorbed by the Safe Network Foundation. What’s not clear in the original proposal is how the foundation will be funded (by private donations or through implied administration fees taken in SNT). Up to now I had always presumed that the foundation finances would not be mingled with the developer pools in any way and it would be funded through donations just like any other foundation. That would be a preferred approach. Non-profit foundations usually rely on endowments, and donations. This is better than network “royalties”. The Bamboo Garden fund is a good example of how the foundation would likely receive large donations that could be made part of an endowment to fund operating costs.

This group will ensure the correctness of the coin issuance and also that every project that is applicable is included in the polling system for funding of that project. The board can put forward their suggestions and conclusions for any funding for projects. The assurance of developer rewards will also be continuously-monitored and managed. This mandate will be kept as minimal as possible to prevent unfair or ill considered decision making.

So yeah, perhaps willfull blindness on my part when I read this the first time. MaidSafe was transparent in their original intention to use a foundation and a board to manage the developer rewards. This is a very practical approach for just getting the network launched, but imo it is not ideal long term and adds a huge attack surface to the network. It would be better if that function could be eliminated. Imo instead of having only a goal of partial automated reward disbursal from the developer pool, all rewards would be automated. This may not be possible for core developer rewards, but the goal should be to minimize the role of the foundation in token distribution after the initial genesis supply is introduced. If there is also a way to eliminate the need for it to issue genesis tokens, all the better. This leaves the foundation to pursue other aims related to educational outreach, hackathons, developer outreach, marketing, patent and trademark protection, legal issues, fund lobbyists, normal non-profit corporate activities and all the “human” related aspirations, benevolence, malevolence, and deficiencies that go along with that, that are by design not directly tied to network functions in any way. This functional partition between in-network and out-of-network roles is important to long term success imo.

7 Likes

My perspective is that launch should either be with the end-state upfront or control of anything not core-dev should be decentralized into the hands of the community, and allowances should be made for consensus-based updates to the network so that any dev can have their contribution accepted/rejected by the nodes directly. Otherwise it’s just a centralized system promising to eventually be decentralized at some unknown, unclear “end-state”.

A recent report by Trail of Bits sponsored by DARPA point to the kind of centralization problems holding back lots of supposed decentralized networks: https://assets-global.website-files.com/5fd11235b3950c2c1a3b6df4/62af6c641a672b3329b9a480_Unintended_Centralities_in_Distributed_Ledgers.pdf

A snippet:

“We show that a subset of participants can garner undue, centralized control over the entire system:
While the encryption used within cryptocurrencies is for all intents and purposes secure, it does not guarantee security, as touted by proponents.”

Safe network should not start with such a glaring weakness.

Another thing is that the discussion isn’t very MECE in general. For instance, if governance and distribution could truly be separated where governance of the safe network is truly in the hands of node operators and other participants while token distribution was still “centralized” with the foundation/maidsafe, I could support such a setup. But it’s hard to achieve such a separation because, even if a system were to be setup where each participating node gets one vote, initial entry onto the network as a node still ultimately depends on control over tokens (i.e., need for capacity and tokens are required to fill the network to create the need for capacity and therefore nodes). There’s more, but let’s focus on that key factor alone for now.

So token distribution ends up being a governance distribution as well. And given the ultimately economic security model of the system (again, tokens required to create need for nodes), more than 33% of the circulating token supply should never be controlled by a single entity at any one time as the current RFC proposes.

1 Like

It’s interesting to read these last few replies. Some great points and dialogue.

I personally don’t have much a problem with foundations or hybrid systems as they tend to be compromises that allow things to accelerate within existing systems or legal structures but I do see pure decentralization as the end goal or holy grail if you will.

I’ve witnessed issues the Tezos Foundation had with an early board member that then went on to vote out and become highly effective in its goals.

OTOH Ethereum has constantly been criticized by bitcoin maxis and others in the crypto sphere for being under such centralized dictatorship via its foundation and Vitalik.

I think @Bogard is correct that we should probably be hearing some from Heather. Tagging @Heather_Burns its always great to hear from you btw, great addition and role filled @maidsafe.

Jim’s expanded role is a lot of responsibility too so I don’t pretend that every piece of input we have is at the top of the list compared to jumping all legal hurdles in the final miles of launch. Which we are all desperate for.

Yet, this is an RFC, these things should be hashed out and perfected first go around, and what is any decentralized project without a strong and mindful community?

Just commentary here as I’m not as technical as others but I do hope being an RFC, that hashed out and published proposals stand a chance of a fair trial.

Again, satisfied with the initial proposal but also open to this increasingly interesting developing discussion.

13 Likes

Just to clear up what seems to be some confusion around my role - my work is on the regulatory affairs/policy/politics governance side, as well as on the project governance side e.g. the structure of the OSS project itself. Token governance is an entirely different discipline, issue, and set of expertise; it’s actually unfortunate that it’s even called “governance” as it causes a lot of conflation of apples and oranges, in the public sphere as well as in community perceptions of what my role involves.

I’m currently doing my best to support Jim on these ideas as they’re fleshed out, with an eye on what sort of secondary issues they could create elsewhere e.g. crossover regulatory issues. Andrew, who’s the financial/crypto/numbers mind on our team, is also supporting on those aspects.

Jim is now off on a well-deserved break with family, but we’ll be picking this up when he returns refreshed.

(BTW, the speculative fiction post I wrote was not about this project, if that wasn’t obvious; it was a very specific dig at a very specific project which has defiantly refused to address any of its corporate control or project governance issues, at all.)

16 Likes