Yup, it’s a post launch one for sure.
4 Likes
This is key, I would propose that if no agreed solution is found then these never see the light of day.
12 Likes
Good to have a clear and understandable fallback, however controversial!
If this were adopted as official policy it would motivate those unhappy with it to come up with alternatives.
There would need to be a cut off, and I think a process for deciding both whether an alternative flies and when the cut off should be.
I think a policy defined before launch, and ideally a decision really.
Otherwise there’s a massive distracting cloud hanging over SNT and a part of the network that a lot of headline generators will focus on.
We want launch interest and post launch discussions to focus on other things so I think this is actually very important. Sorry Jim 
Any bright sparks got a technical solution to shortcut all of this? Maybe we should put up a bounty from the BGF?
8 Likes
Good idea. I think that if we can get to a place where there is an emission schedule that is automatic and not game-able then we should make a decision that only if we achieve such a system then there is no debate. The network will use that emissions mechanism.
So perhaps @JimCollinson @happybeing we say this:
The 70% emissions will only happen when there is a proven mechanism in place that is provably secure and there are no known attacks beyond those that exist in the Safe network.
I bound this with the attacks beyond those of the core network as the network is probabilistic, i.e. an attack like “I could guess a key” are not an attack as we can guess satoshi secret key. It’s an attack, it’s provable, but it’s infeasible.
9 Likes
This is the official policy decision BTW, from the accepted RFC:
It is assumed that this process, which is subject to further research and development, will not be in place a the inception of the Network, but will be implemented via a future Network update.
It’s not on MaidSafe’s roadmap for a technical resolution prior to launch.
10 Likes
Then we will launch with a massive uncertainty hanging over the future issuance and max supply.
I see it is too late to change that short of a really neat solution preempting this (pre launch) but the significance hadn’t dawned on me.
I have been thinking about it since I posted
EDIT: maybe I make too much of it and it won’t be a big deal if presented well 
2 Likes
Why not just add in one of those horrible proof of work systems? Even more simply, just fork the monero code and adapt it, then make a bridge to convert the generated tokens into DBC’s.
As a MAID hodler I’m not completely opposed to the 70% going away, but I think it would raise the hackles of those who are looking for decentralized solutions and give us a lot of negative energy from the broader crypto community.
Edit … just had another thought. We could use the emissions from an EXISTING coin by only allowing them from a certain block height. So could use bitcoin. Take the remaining bitcoins to be mined, and then when bridged to SN you get a multiple (of SNT) based on desired rate.
3 Likes
Only if it is indefinite right?
Would a limit on finding a solution help, no solution found within 2 years of launch call it quits and officially change the supply cap.
5 Likes
Is is not ideal, but I see it as better that delaying launch while looking for nicest solution.
3 Likes
There’s no question of delaying launch.
7 Likes
This is precisely the conclusion we came to through the whole RFC process, and it’s the right approach given the constraints.
7 Likes
I probably should have kept my 
But what harm is there from not including the 70% besides over time token price increasing and moving more quickly down the available divisibility?
Is the amount divisibility without the 70% even a concern?
Interesting questions but for Jim and launches sake, the RFC is scripture to me at this point. There is language in there that kind of states “we can deal with this later” and we can, so.
1 Like
My concern is over uncertainty about a) total supply and b) the interval over which an additional issue of more than twice the genesis supply are created. That is, lots of FUD.
I’m not sure how big an issue it will be in practice, but I’m pretty sure haters and competitors will try to make it one - just when we’re trying to highlight all the amazing innovations of the network. So it could be a significant distraction.
Anyway, I should stop posting about it and go think of a solution 
. As if 
. But first I better walk the 
6 Likes
I’ll grant you that is a lot of uncertainty, if one is to assume the exclusion of the 70% then definitely fear but best to assume the inclusion which was the plan all along.
If excluded that really is a bunch of gravy for a token holder as less supply should mean, higher market cap, and higher token price.
2 Likes
I havent really followed the technical ins and outs but if the 70% isn’t needed given the route the network development has now taken, then better to bin them now or issue them all when MAID holders convert to SNT. The solution must involve a clean cut from this overhang.
Otherwise it will just be a burden to the entire project forever, driving users away. Plus an acceptable solution will become more difficult as more people get involved.
4 Likes
Good point! Plenty of evidence of this out there.
5 Likes
It’s not like people haven’t had time to buy some MAID… or to put a value on the possibility of something like this happening.
3 Likes
The issue isn’t that with or without the 70% is good or bad, the issue is the uncertainty that this creates which is IMO bad for the reasons I’ve given.
Much as I’d prefer we stuck to the original plan and issue it over time, it is clear we can’t know that will happen.
The only way to create certainty would be to abandon that idea and, as @Astroman suggests, either bin the 70% idea or just issue them all to existing holders.
I don’t like any of these options, but my preference is for certainty.
It may be too late to go for that now if it would reopen the RFC and undermine the legal stuff which is based on it. I just hadn’t realised this until now 
11 Likes
Anything that affects holders in a positive way should not become a legal problem.
2 Likes
Conceptually, would it be possible to;
-
Mark all farming reward DBCs uniquely as ‘unspent farming rewards’ in a way that can’t be faked, and where the status is lost if spent as SNT.
-
Have the 70% of SNT in a pot that is only accessible in exchange for ‘unspent farming reward’ DBCs via a simple exchange (DEX or foundation hosted).
-
The exchange will swap ‘unspent farming reward SNT’ for SNT at a ratio of greater than 1 until the stock of SNT in the pot is gone (e.g. 1 unspent farming reward SNT = 1.1 SNT).
Probably not workable, but I’ll throw it out there.
Over time I have come to prefer the idea of farming rewards eventually being the primary source of SNT supply over the supply of early investors and MAID holders. But I can imagine serious issues if there is uncertainty about a possible 70% dilution at, or after launch. Carrying this uncertainty beyond launch may well be worth avoiding.
2 Likes