Updated: RFC 0061 — Safe Network Token Distribution

Any excuse

all knobs to 11.

3 Likes

Okay. Don’t mean to cause confusion to others. I mean specifically the token distribution portion but mostly that if this is a hindrance on network delivery and a majority agreed, what are we still all going on about? It seems like just one single person at this point. @zeroflaw

I think the other proposal for token distribution is decent but not enough of an improvement to impede launch or lengthen timescales any further than necessary.

I commend the team for being so patient and open to the process but also understand David’s frustration with roadblocks like what we’re seeing right now. Most of us just all want to get on already and if we were all that dissatisfied, Maidsafe would know it but we’re not.

3 Likes

@zeroflaw if you decide personally to contact lawyers, send emails to regulatory boards, pay for legal opinions, etc etc, could you please do so on your own time instead of polluting this thread, and in so doing, rotting everyone’s skull? Your behaviour is, quite frankly, petulant. I’m not going to count up the times you’ve repeated yourself, but come on…

Asking what you quite possibly perceive as your “question” the first time, fair enough, then repeating it when you feel you haven’t got the desired outcome, even a third statement of the point, ok, I get it, but at this point, give us all a break? You’ve gotten your response, whether you like it or understand it is your own problem.

In summary - you’re derailing this thread, and your ceaseless reptitions could legitimately be classified as off-topic and/or spam in my opinion, and I’m kind of surprised you haven’t gotten a ban from the topic. There’s insisting on one’s point while remaining polite and focused, which @jlpell provided an admirable example of, and then on the other end of the spectrum, there’s your behaviour.

tl;dr For the love of Satan, @zeroflaw, spare us the repetitive whining, either contact lawyers or don’t, this thread (and community) owes you nothing

5 Likes

For my own part - catching up on all this after being away for a bit is rough. @jlpell’s solution sounds clean, but I don’t see anything particularly egregious about @JimCollinson and the team’s proposal either. So put me firmly in the camp of - can we just do something, and move on to more important things. The Network being made is what matters

10 Likes

Mods, the trolling is clear, the threats now explicit, this thread has become impossible to follow and filling with repeated mistakes that can’t be cleared up because there is so much garbage clouding the discussion.

Please can you suspend or ban the culprit so we can bring this to a conclusion.

6 Likes

I will not comment on the correctness of any one approach, lets just say I am extremely encouraged by the passion shown by all.
Heres another very practical way you can show your passion for the project.

3 Likes

True. Everyone please stick to discussion about specifics of the RFC and refrain from personal attacks.

6 Likes

ok yeah, I haven’t been watching this closely. If that’s the case, I’m sorry for and retract the (harsh?) statement. (as I said above).

I wonder if you could please make a statement in regards to:

To me, it seems cleanest and fairest to keep max supply 2^32 as promised, keep existing hodlers percentages unchanged, and only alter percentages for newcomers with no skin in the game.

At the least, I would like to see the “keep RFC as-is” camp address if this is an approach they would consider, or if not, why not?

and with that, I will happily bow out of this thread. good luck finding a solution y’all!

8 Likes

And this failed. Have you a time machine to fix it. Obviously we cannot so which do you keep the 429496729 or the 10% since both were equal in the plan?

The issue is we have to live with the error and how to deal with it. Keep the 10% rule or keep the 2^32 and at this point the 2 proposals have significant problems when trying to be dogmatic with the white paper.

BTW where did that quote come from, some financial prospectus?

Like I said I am happy with both proposals (except some wording), and I see no significant material losses either way unless markets reject the “A” version because it appears to the markets to revert to original plan and rejects the evolution that has happened.

My thought experiment suggests there is no loss with either version. Legal basis is significant material loss, and a change from a plan barely cuts it as a reason. If it was a registered prospectus or a security promise then yes changes can be a legal problem.

The original plan was broke when the over mint happened. And the team worked hard through the many options to try and come up with a solution that does not disadvantage any group. Version “A” does have a slight disadvantage to the app&core devs now and in the future. But otherwise they have the same effects really for the MAID holders and others.

To change now though will cause more work, time and reviews by the community.

1 Like

What a great song!

2 Likes

How many tokens do you have? I will buy that all and please leave here. I dont like keyboard attacking. Send me DM.

2 Likes

You should hear the original by our own wee Scottish lad Eric Bogle. He wrote it. Check it out on the tube. Also waltzing matilda. Very much questioning war and it’s outcomes. Great stuff

4 Likes

But the proposed solution not only fails to address this problem, it makes it even worse.
The fact that it also concentrates all the loss on one particular group makes it, as I keep insisting, very dangerous.
The people of Maidsafe, the company and the two foundations (Swiss and Scottish) must be protected as much as the network itself.
The enemies of this project will not hesitate to attack any weak flank they can find, so it is imperative to leave none behind.

From Maidsafe.

These are the public terms of the Crowd Sale and, therefore, have a legal binding which, in case of non-compliance, could lead to a legal action.

That’s why I think it’s so important to keep the max supply at 2^32 at all costs.

Solutions?
The simplest is to reduce the Remaining Tokens, which would only drop by 0.54%. For practical purposes it would not affect anything.
imagen

The other solution, which would personally piss me off a lot, is to reduce the Extra Maids from the Network Royalties Pool.
If these Extra Maids were used for the development of the project, it makes sense to allocate them to this pool.
Legally, this seems to me, by far, the least problematic solution.
imagen

Of course the people at Maidsafe have put many hours of thought into the making of this RFC and will have considered these solutions as well as consulted with legal experts.

If they still believe that the original solution is the right one, despite the problems some of us have encountered, go ahead with it.

The worst that could happen is that the project could be delayed even further.

1 Like

Yes, true.

Yes, I see your point here and agree. I thought my original suggestion to have the foundation handle the overprint via an ad hoc payment would create the least disturbance and bring up the point that the core development team should still get 5% of max supply based on the whitepaper promises. But to be perfectly honest, you are completely correct here.

The overprint issue can/should be viewed as an advance on the 5% that was promised to the core team. I will revise RFC0061A to reflect this.

I don’t think it is ethically proper to break the 70/30 split between future contributors and past/present ones. I agree that @oetyng’s suggestion is the most proper.

I strongly disagree with the above statement when it comes to the day 1 injection of the Genesis Supply. The whitepaper was very clear how much was promised to core developers and that 5% should be honored in some fashion.

That’s a utilitarian perspective and may have little consequences, but it is not the correct choice here. @oetyng hit the nail on the head in his comment above with the correct course of action imo.

Yes, agreed.

I have no knowledge of Swiss procedure, but depending on how much detail has been submitted in the foundation paperwork, there may be no need to derail anything. Perhaps a few amendments may be all that are needed? Correcting something like the requested max token issue from 4525524120 in the application to 4294967296 in the network means a simple burn of the difference in terms of foundation bylaws, no?

3 Likes

What you described is what was proposed here.

1 Like

Not exactly. You add a payment of 100K. I don’t know why, which seems to me to be totally inadequate.
In fact it looks like a bribe that raises legal issues which is exactly what we want to avoid.

That’s actually in the original safecoin white paper, and we don’t agree it is right to keep it there, so that’s why it doesn’t feature in this RFC.

1 Like

Like Jim said, I only included it because it was promised in the whitepaper. If there is another way to pay the interested party and keep that promise to their liking, then it would make sense to eliminate it from an RFC.

2 Likes

Not really since the network doesn’t exist yet. The initial resource pool is for work done after the pool is created. The sale of the 23 million went to the initial development of the network to get it to launch.

This is also what the white paper was saying. There was the 100K$ repay the dev team for work done to get to launch. But as @JimCollinson said its not really fair and that would be because of the various funding sources has paid them already including the 23 million.

The resource pool though apart from the 100K$ was for work done after launch.

This is why developing the RFC is not quite as easy as it seems and trying to be dogmatic is showing up problems and the RFC0061A has the 100K$ in it so trying to say the 23 million sale was part of teh resource pool is a double error

2 Likes

So true.

Even the ‘simple’ solutions turn out to be very complicated and take a lot to work through. There are a lot of moving parts involved that often conflict. Nothing is simple with humans and money.

11 Likes