This probably is best for a dedicated thread I’d have thought, because while it does related to this RFC, it is a chunky topic in itself and can (and has been) been discussed in parallel.
1 Like
It has been? Do you mean something related to this idea or this idea specifically, because I didn’t find anything when I searched.
I will make a thread soonish if nobody else does.
It’s cropped up in various places. Specifically the idea you describe actually, through various interpretations of what a “lock box” concept might entail.
But it’s usually in comments under dev updates, so best to have a dedicated thread.
Cool, okay. I’m not referring to a network controlled lock box though. But will detail it again in a new thread. Thanks for the feedback.
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 
—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 
[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.
6 Likes